Grundlagen und Modelle des Information Lifecycle Management 9783540690818, 3540690816 [PDF]

Zitiervorschau

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Günter Thome · Wolfgang Sollbach

Grundlagen und Modelle des Information Lifecycle Management Mit 116 Abbildungen

123

Günter Thome Am Forsthof 20 52459 Inden [email protected]

Wolfgang Sollbach Finkenweg 1 49536 Lienen [email protected]

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISSN 1439-5428 ISBN 978-3-540-69079-5 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3100 YL – 5 4 3 2 1 0

Einleitung

Die erfolgreiche wirtschaftliche Entwicklung eines Unternehmens hängt in hohem Maße von qualifizierten und richtigen Entscheidungen ab, die vor dem Hintergrund eines beständigen organisatorischen Wandels zu treffen sind. Der Wandel sowohl im Wettbewerb als auch in der eigenen Unternehmensorganisation kann dabei Formen wie Prozessorientierung, Segmentierung oder Virtualisierung annehmen. Konventionelle IT-Architekturen betrieblicher Informationssysteme sind diesem beständigen Wandel, der auch bei Fusionen oder starkem Wachstum stattfindet, häufig nicht gewachsen. Eine effiziente und leistungsfähige IT-Infrastruktur ist deshalb der Wunschtraum vieler Unternehmer. Nur die Unternehmen können schneller auf veränderte Geschäftsanforderungen reagieren, deren IT sich nach den Geschäftsprozessen richtet, die das jeweils benötigte Wissen in Form von geeignet aufbereiteten Informationen bereitstellt, und nicht umgekehrt. Basierend auf der Forderung nach strukturellen Analogien zwischen Unternehmensorganisationen und Informationssystemen wurden deshalb in den letzten Jahren eine Reihe unterschiedlicher Ansätze entwickelt, die von der stärkeren Integration (BI, EAI) über spezifische Ausrichtungen (mySAP) bis zum Outsourcing der gesamten Informationstechnologie reichen. Alle Ansätze werden mit der steigenden Komplexität der Informationstechnologie und der progressiven Kostenentwicklung des Sektors IT begründet. Kernthemen sind dabei Mainframe-Konzepte, Server-Architekturen und die Intelligenz von Clients, die Virtualisierung und die Serviceorientierung der Software (SOA). Die dringend notwendige Entscheidungsobjektivierung auf Basis einer strukturierten Vorgehensweise, einer ganzheitlichen Problemsicht und durch den Einsatz pragmatischer Methodenbausteine ist jedoch erst dann gegeben, wenn auch die Speicherung und die Bereitstellung von Informationsservices gemäß den Anforderungen des Geschäftsprozesses die ihr gebührende Berücksichtigung in einer IT-Architektur findet. Moderne Speichersysteme sind längst mehr als nur einfache Festplatten. Mehr und mehr verlagert sich die Intelligenz aus dem Betriebssystem des Servers in das Speichersystem. Information Lifecycle Management (ILM), Hierarchical Storage Management (HSM) und viele andere aktuelle DV-Schlagwörter und DV-Verfahren betrachten jedoch üblicherweise lediglich Techniken und Verfahren zur kostenangepassten Speicherung von Informationen gemäß ihrem Alterungsprozess. Dabei wird viel zu wenig auf die (gesetzlichen) Anforderungen und die betrieblichen Notwendigkeiten abgehoben, die ein ILM aus kaufmännischer und Gesamtunternehmenssicht erforderlich machen, und auch selten die

VI

Einleitung

Intelligenz in den Speichersystemen betrachtet. Mit ILM wird der Information erstmals neben dem Charakter eines Produktionsfaktors auch die Eigenschaft eines Produktes zugestanden, das einem Lebenszyklus wie jedes andere Produkt unterliegt. Innerhalb der einzelnen Phasen dieses Zyklus muss die Information entsprechend ihrem Wert für das Unternehmen DV-technisch behandelt werden. Dieses Buch beschreibt, aufbauend auf den Innovationen im Storage Area Network (SAN) und im Network Attached Storage (NAS) sowie bei der Virtualisierungstechnologie, aufgrund welcher gesetzlichen und ökonomischen Grundlagen ILM ein Muss-Thema für jeden CIO eines jeden Unternehmens ist. Auf dieser Basis wird beschrieben, wie ein Projekt zur Implementierung eines ILM aufgesetzt und durchgeführt werden muss. Im Anschluss werden die technischen Realisierungsansätze der gängigen Hersteller dargestellt, mit denen diese auf die betrieblichen Anforderungen reagieren. Die beiden Bücher „Grundlagen und Modelle des Information Lifecyle Management“ und „Information Lifecyle Management – Prozessimplementierung“ beschreiben sowohl den klassischen Ansatz der Information als Produktionsfaktor, der einen gewissen Lebenszyklus (Alterungsprozess) durchläuft, als auch den Ansatz, der der Information den Produktcharakter zugesteht und dabei der Information einen Produktlebenszyklus zuweist. Ohne die Erweiterung der Sicht auf die Information würden neue Geschäftsmodelle keine Berücksichtigung finden, die heute lediglich auf dem Auffinden von Informationsinhalten und Quellen basieren – vgl. Google –, die aber in der nahen Zukunft immer größere Bedeutung auch in den Unternehmen gewinnen werden. Um wettbewerbsfähig zu bleiben, muss der Produktionsfaktor Information systematisch gestärkt und effizient genutzt werden. Für eine höhere Effizienz und Produktivität steht heutzutage in den Unternehmen sowohl die „richtige“ Nutzung der Ressource Wissen im Vordergrund als auch die Vernetzung der Mitarbeiter, die über das Wissen verfügen. In der Praxis fehlt es jedoch häufig an der Umsetzung. Wie die Fraunhofer-Studie „Wissen und Information 2005“1 zeigt, halten immerhin 91 Prozent der Unternehmen das Thema für „wichtig“ bis „sehr wichtig“. Vor dem Hintergrund der globalen Veränderungen werden sich die Informationsbedürfnisse von Unternehmen und Führungskräften ebenfalls rasch ändern. In den vergangenen Jahren lag der Schwerpunkt auf der Verbesserung der traditionellen Formen der Informationsvermittlung, bei der es fast ausschließlich darum geht, was sich innerhalb einer Organisation abspielt. Auch die Daten, die von der Mehrzahl der neuen Informationssysteme hervorgebracht werden, dienen diesem Zweck. Und tatsächlich beziehen sich annähernd 90 Prozent oder mehr der von einem Unternehmen gesammelten Informationen auf unternehmensinterne Vorgänge. Doch eine erfolgreiche Strategie wird in zunehmendem Maße Informationen über Vorgänge und Bedingungen außerhalb der Organisation erfordern: Kenntnisse über Nichtkunden, über bislang weder vom Unternehmen noch von seinen Mitbewerbern genutzte Technologien, über noch nicht erschlossene Märkte und  1

www.fraunhofer-studie.de.

Einleitung

VII

so weiter. Nur im Besitz solcher Informationen wird ein Unternehmen entscheiden können, wie es seine Ressourcen einsetzen muss, um Höchsterträge zu erzielen. Nur mit solchen Informationen kann das Unternehmen sich auf neue Situationen und Anforderungen einstellen, wie sie aus plötzlichen Verwerfungen in der Weltwirtschaft sowie aus der Art und den Inhalten der Information selbst hervorgehen. Die Entwicklung rigoroser Methoden zum Sammeln und Analysieren externer Informationen wird für Unternehmen und Informationsexperten zur Herausforderung. Künftig wird der Schwerpunkt der Managementtätigkeit darin liegen, neue Konzepte, Methoden und Praktiken zu entwickeln, um die Informationsressourcen nutzbar zu machen. Das zentrale Element der neuen Organisation ist dabei der Datenspeicher und sein Management. „Information Lifecycle Management (ILM)“ beschreibt das Management und nutzt Information als Produktionsfaktor. ILM ist eine Managementphilosophie, durch die die Unternehmen ihre Datenbestände und damit ihren Produktionsfaktor Information optimal einsetzen können. Bei der Sichtweise, Information als Produkt aufzufassen, unterliegt die Information – wie jedes andere Produkt auch – einem Lebenszyklus. Hierunter ist für „Information“ die erwartete oder aus der Vergangenheit interpolierte Nutzbarkeit der Information bis zu ihrem Ausscheiden aus dem Informationsportfolio des Unternehmens zu verstehen. Wie jedes andere Produkt durchläuft auch die Information zunächst eine Einführungsphase, in der die Kosten der Informationsgewinnung und Informationshaltung den Nutzen der Information übersteigen. Hier ist die Information am „wertvollsten“, weil am aktuellsten für das Unternehmen. Hier entscheidet sich, ob durch geeignete Nutzung der Information zukünftig der Ertrag aus der Information die Kosten der Information übersteigen wird. In ihrer Wachstumsphase wird Information gewinnbringend in die Geschäftsprozesse des Unternehmens eingebaut. In dieser Phase erhöhen sich evtl. noch die Kosten der Informationshaltung, die Erträge der Information steigen. In der Reifephase halten sich die Kosten der Information in Grenzen, der Gewinn erreicht sein Maximum. Hier ist die gewonnene und gespeicherte Information selbstverständlicher Teil der relevanten Geschäftsprozesse des Unternehmens geworden. Die Sättigungsphase wird erreicht, wenn die Information zur Selbstverständlichkeit aller Marktteilnehmer geworden ist, das Unternehmen also keinen Wettbewerbsvorteil aus dem Besitz der Information mehr erzielen kann. In dieser Phase muss massiv über die Gewinnung neuer Informationen nachgedacht werden. Die Degenerationsphase beschreibt den Status der Information als für die Geschäftsprozesse des Unternehmens nicht mehr relevant. Über sämtliche Phasen des Produktlebenszyklus der Information spielt eine Vielzahl von internen und externen Parametern eine Rolle, die die Gewinnung, Speicherung und Nutzung der Information stark beeinflusst. So gibt der ordnungspolitische Rahmen moderner Industriegesellschaften einen Kanon juristischer Vorschriften im Umgang mit Information vor, wie bspw. die Anforderung, geschäftsrelevante Daten bis zu 30 Jahre zugreifbar zu halten.2 Der „Wert“ der  2

Vgl. www.aerzteblatt.de/v4/archiv.

VIII

Einleitung

Information als Wettbewerbsinstrument klassifiziert Informationen in diverse Vertraulichkeitsstufen. Auch hier existiert ein umfangreicher juristischer Komplex (BSI3) bzgl. des Schutzes von Informationen (bspw. personenbezogener Daten). Bei dem Rating von Aktiengesellschaften gemäß Basel II4 durch Banken fließen so genannte „weiche Faktoren“ mit bis zu 60 Prozent in die Bewertung des Unternehmens ein. Zu den weichen Faktoren gehören unter anderem auch das Informationsportfolio des Unternehmens bzgl. seines Marktes (Mitbewerber, Kunden) sowie die Nutzung dieses Portfolios z. B. durch eine sozial verantwortliche Außenwirkung des Unternehmens. Vergleichbar Basel II befassen sind die deutschen Versicherungen zurzeit mit der Umsetzung von Solvency II, einem Ansatz zum strategischen Risikomanagement, der besondere Anforderungen an die Qualität und die Verfügbarkeit von Daten stellt. Auch beim Information Lifecycle Management mit dem Fokus auf Information als Produkt besteht die Notwendigkeit, dass die Unternehmen ihre Datenbestände in den Griff bekommen. Mit ILM steht bei Investitionen im Speicherbereich nicht mehr der Aufbau von Kapazität im Vordergrund, sondern ein besseres Management der gespeicherten Daten. An ein explosionsartiges Wachstum der klassisch zu speichernden Datenmengen glauben deshalb einer Studie der HitachiTochter Hitachi Data Systems (HDS) zufolge immer weniger IT-Verantwortliche. Die große Mehrheit der befragten Führungskräfte rechnet für die kommenden zwei Jahre lediglich mit einem Wachstum ihrer Datenbestände von 30 Prozent. Die großen Anbieter setzen deshalb verstärkt auf Beratungsdienstleistungen und Software. Die Anbieter von Speicher zeigen so dem Kunden, wie sie effizienter mit dem Equipment arbeiten können, das sie bereits haben. Massive InfrastrukturInvestitionen im Gleichschritt mit steigenden Datenvolumen sind durch ILM nicht mehr nötig. Die Computerwoche berichtet auf der Seite für Zahlen, Prognosen und Trends unter der Überschrift „Im Fokus: Information Lifecycle Management“: „Die Meinungen, was Information Lifecycle Management (ILM) eigentlich bedeutet und was es impliziert, gehen weit auseinander.“ 5 Die Marktforscher der Experton Group haben untersucht, wie sich Unternehmen des Themas ILM annehmen.6 Demnach haben 3,5 Prozent der 200 befragten IT- und Speicherverantwortlichen ILM unternehmensweit komplett umgesetzt. Weitere 25,5 Prozent haben punktuell Erfahrungen gesammelt und hegen kurzfristige Umsetzungspläne. Das Gros der Befragten (47,5 Prozent) plant langfristig die – zumindest teilweise – Umsetzung, und nur 22 Prozent verfolgen keine entsprechenden Projekte. Ziele, die mit ILM-Projekten erreicht werden sollen, sind an erster Stelle Business Continuity und Disaster Recovery (12,3 Prozent), gefolgt von der Bewältigung der ständig ansteigenden Datenflut (10,5). Zudem ist die Einhaltung gesetzlicher Bestimmungen (9,3) ein Treiber, ebenso die allgemeine Kostenkontrolle (7,4) und das Bestreben, Server- und  3 4 5 6

BSI – Bundesamt für Sicherheit in der Informationstechnologie, www.BSI.de. Vgl. www.basel-ii.info. www.computerwoche.de, 15/6 vom 14. April 2006, Seite 50. www.experton-group.de.

Einleitung

IX

Speicherlandschaft zu konsolidieren (6,8). Rund die Hälfte der Befragten hat bereits die technischen Grundlagen für ILM geschaffen. Dazu zählen Konsolidierung der Server- und Speicherumgebung sowie der Backup- und RecoveryArchitektur. SAN- (Storage Area Network) und NAS-Konzepte (Network Attached Storage) sind von 44 bzw. 31 Prozent der Befragten umgesetzt. Insgesamt 40 Prozent wollen ein zentrales Storage-Resource-Management (SRM) aufbauen – Ende 2005 waren allerdings erst 19 Prozent so weit. Folgt man dieser Bewertung, so steckt Information Lifecycle Management aktuell noch in den Anfängen. Zudem gibt es noch keinen allgemein akzeptierten Standard. Die großen Speicheranbieter beginnen hier erste marktfähige ILMProdukte und Dienstleistungen anzubieten, d. h. wir befinden uns erst in der Einführungsphase, d.h. es ist noch keine klar erkennbare Orientierung vorhanden. Natürlich realisiert jedes Unternehmen mehr oder weniger explizit oder implizit Aktivitäten im Sinne eines ILM-Konzeptes im Streben, schon heute die gesetzlichen Vorgaben und die Anforderungen der Geschäftsprozesse, die Compliance, zu erfüllen. Der sehr unterschiedliche Wissensstand der Entscheidungsträger über ILM als Strategie und den Umsetzungsgrad der ILM-konformen Ansätze hat uns, die beiden Autoren, veranlasst, das Thema in zwei Bänden abzuhandeln, um die für den Leser im Sinne eines Dienstleisters jeweils relevanten Informationen kompakter und zielgerichteter vorstellen zu können. Die beiden Bände „Grundlagen und Modelle des Information Lifecycle Management“ und „Information Lifecyle Management – Prozessimplementierung“ haben zusammen den Anspruch, über den klassischen Hardware- und Softwarelösungsansatz hinaus das gesamte für ein Information Lifecycle Management relevante Umfeld zu beschreiben. Grundlagen und Modelle des Information Lifecycle Management Im vorliegenden Band werden die ökonomischen und juristischen Grundlagen für Information Management und Information Lifecycle Management erläutert. Das Aufzeigen der Grundlagen macht deutlich, dass die Einführung und Optimierung eines Informationsmanagements (IM) und Information Lifecycle Management unabdingbar für den juristisch einwandfreien und ökonomisch sinnvollen Einsatz der IT erforderlich sind. Hierbei wird die Bedeutung der Information und der an sie gebundenen Geschäftsprozesse erläutert. Es wird ein geschäftszentriertes und vereinheitlichtes Informationsmanagement beschrieben, bei dem auf den Wert der Information abgehoben wird. Es wird dargestellt, dass eine Policybasierte Infrastrukturanpassung an diesen Wert der Information erfolgen muss. Im Abschnitt über den Produktlebenszyklus des Produktes und des Produktionsfaktors Information wird das betriebswirtschaftliche Konzept des Produktlebenszyklus beschrieben und – ausgehend von diesem – der Lebenszyklus des Produktes Information erarbeitet. Die juristischen Grundlagen des Informationsmanagements und Information Lifecycle Management stellen die Anforderungen dar, die von ordnungspolitischer Seite heute an die IT eines Unternehmens gerichtet werden. Vorstandsund Aufsichtsratsmitglieder einer AG, Geschäftsführer einer GmbH sowie die

X

Einleitung

geschäftsführenden Gesellschafter einer OHG oder KG, d. h. die Geschäftsleiter, sind zunehmend einem persönlichen Haftungsrisiko ausgesetzt. Dies gilt auch für schwere Fälle von Datenverlust in Unternehmen. In der Gesetzgebung und Rechtsprechung sind Tendenzen feststellbar, dass Geschäftsleiter verstärkt von ihren Gesellschaften in die Haftung (Regress) genommen werden können. Bereits seit der „ARAG-Garmenbeck“-Entscheidung des BGH vom 21.04.19977 steht fest, dass der Aufsichtsrat einer AG grundsätzlich dazu verpflichtet ist, durchsetzbare Schadensersatzansprüche gegen Vorstandsmitglieder zu verfolgen. Nur in Ausnahmefällen darf der Aufsichtsrat davon absehen, einen Schadensersatzanspruch geltend zu machen. Darüber hinaus wird die entsprechende Bereitschaft zur persönlichen Inanspruchnahme der Geschäftsleiter auch durch die Verbreitung des Shareholder-Value-Gedankens bei Aktionären und Gläubigern gefördert. Die spezifischen Anforderungen machen es notwendig, auf den Sarbanes-Oxley Act (SOX), Basel II, Solvency II, das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG), das Transparenz- und PublizitätsGesetz (TransPubG), die Regelungen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GdPdU), die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) und das Handelsgesetzbuch (HGB) detaillierter einzugehen. Die innerbetrieblichen Anforderungen an die Datenhaltung sind ein weiterer determinierender Parameter für die Notwendigkeit eines Information Lifecycle Management. Hier beleuchten wir juristische und betriebliche Anforderungen an Datenschutz und Datentypen, die aus dem BSI-Grundschutz entspringen. Wir betrachten die Anforderung an Echtzeit- oder echtzeitnahe Recherche sowie als deren Voraussetzung, Policies und Verfahren zur Datenspeicherung. Daraus resultiert die Erkenntnis, dass eine einheitliche, konsolidierte Anwendungs- und Datenlandschaft für ein effizientes Management notwendig ist. Abschließend betrachten wir die Serviceanforderungen, die an das Information Lifecycle Management gestellt werden. Hier gilt es insbesondere, die Verfügbarkeit (Availability) für Application Services, den Zugriff (Access) für ContentServices, die Business Continuity und Migration für Data Management Services und letztlich die Virtualisierung und Spezialisierung für Plattform-Services zu behandeln. Auch für ILM-Projekte gilt: „Auch der längste Weg beginnt mit dem ersten Schritt.“8 Sie sollten nach dem Studium des Buches vor dem Hintergrund der beschriebenen Anforderungen und Risiken nicht zu der Erkenntnis gelangen, dass ILM für Ihr Unternehmen zu anspruchsvoll oder zu komplex ist. Wichtig für uns ist, dass Sie die Erkenntnis aus der Lektüre mitnehmen, dass ILM weder eine Laisser-faire-Vorbereitung noch eine Nonchalance-Durchführung erlaubt. In einem kurzen Abriss werden hier deshalb die wichtigsten Projektaktivitäten vorgestellt.  7

8

BGHZ 135, 244 = NJW1997, aus www.uni-frankfurt.de/fb/fb01/ifawz1/segna/files/0607/koll-0607-synopsis.de. Chinesische Weisheit, www.onlinecat.de.

Einleitung

XI

Allen Lesern, die nach der Lektüre dieses Buches die sicher notwendigen Detailinformationen für die Vorbereitung konkreter ILM-Projekte nutzen möchten, sei deshalb hier Band 2 empfohlen. Information Lifecyle Management – Prozessimplementierung Im Buch „Information Lifecycle Management – Prozessimplementierung“ beschreiben wir, die beiden Autoren, deshalb ausführlich ein ILM-Projekt in allen relevanten Details. Wir zeigen Ihnen auf, dass sehr wohl ILM-Projekte auch aus wirtschaftlicher Sicht vorteilhaft sein können und dass die beschriebenen Risiken zu managen sind. Das Buch hat als Schwerpunkt die Implementierung der thematisch im vorliegenden Band vorgestellten Grundlagen und Modelle. In einem kurzen Abriss werden in Kap. 1 und 2 deshalb nur die wichtigsten Informationen zum Thema ILM vorgestellt. Den Abschluss bildet die Beschreibung des sich klar abzeichnenden Trends, Speicher und Sicherheit in einer Lösung zu vereinen. Dabei machen wir eindringlich deutlich, dass es ohne ein systematisches Management der Informationen keinen wirksamen Schutz gibt. Dazu wird unter Berücksichtigung der empfohlenen spezifischen Security-Policies der einzelnen Hersteller ein gesamthaftes Sicherheitskonzept im Rahmen eines ILMKonzeptes geschickt geknüpft. Im Kap. 3 Information Lifecycle Management – Projektorganisation und -struktur sowie im Kap. 4 Information Lifecycle Management – der Projektverlauf – wird dargestellt, wie ein Projekt zur Implementierung eines Information Lifecycle Management geplant, aufgesetzt und durchgeführt werden muss, um den beschriebenen Anforderungen gerecht zu werden. Wir zeigen auf, dass die Komplexität der Aufgabe eine Herauslösung des Themas aus dem Tagesgeschäft zwingend postuliert. Die erste Phase des Projektes stellt die Prozess- und Informations-Istaufnahme dar, auf deren Grundlage danach die geschäftszentrierten IT-Prozesse definiert werden. Dieser folgt das Assessment zur geschäftszentrierten und Policybasierten Infrastrukturanpassung an den Wert der Informationen. Hier erfolgt die Klassifikation der Daten und Anwendungen nach klassischen Geschäftsregeln sowie die Beschreibung der Implementierung von Policies anhand von Informationsmanagement Tools. Ferner wird die Klassifizierung von Speicherressourcen zur Anpassung an Datenklassen zur Repräsentation der Informationswerte vorgenommen. Darauf aufbauend werden klassische Anforderungen an die „tiered“ Speicherinfrastruktur (Hardware und Software) abgeleitet, definiert und beschrieben. In der erarbeiteten ILM-Entscheidungsmatrix werden sämtliche aus unserer Sicht relevanten Parameter/Anforderungen an IM/ILM-fähige Hard- und Softwaresysteme beschrieben und mit einer gemäß unseren Erfahrungswerten aussagekräftigen Gewichtung versehen. Für die Projektphase Ausschreibung und Herstellerauswahl zeigen wir, wie die Ausschreibungsunterlagen zu erstellen sind. Dieser Abschnitt enthält auch ein technisch detailliertes Pflichtenheft, das zur Ausschreibung an die in Frage kommenden Hersteller versandt werden muss. Außerdem beschreiben wir die Planung der Projektphase Implementierung der

XII

Einleitung

Geschäftsprozesse und „Tiered“-Speicherinfrastruktur sowie die Projektphase Migration (Daten- und Servermigration) sowie das kontinuierliche Qualitätsmanagement im Projekt und über das Projekt hinaus. Abschließend werden die Technologien, Produkte und Verfahren der marktrelevanten Hersteller und Integratoren zur Implementierung eines ILM dargestellt. Zunächst wird hinsichtlich ILM das Regelwerk der Storage Networking Industry Association (SNIA) untersucht und der Frage nachgegangen, ob es seitens der Herstellervereinigung Vorgaben oder evtl. sogar Standards zur Implementierung gibt. Dieser Einleitung folgend werden dann zunächst die ILMAnsätze der Hardware-Protagonisten und Generalisten vorgestellt. Hier sind mit EMC2, HP, IBM, SUN (StorageTek) und Hitachi Data Systems (HDS) insbesondere die großen fünf im Markt für externe Speichersysteme gefragt. Es werden aber auch die Ansätze von Network Appliances (NetApp), Fujitsu Siemens Computers (FSC) und Dell beschrieben, um die in Europa gängigen Systemlieferanten komplett abzudecken. Beschrieben werden auch die Lösungen des in Europa führenden SAN-Lieferanten Brocade, der während der Erstellungszeit des Buches seinen in der EU einzig relevanten Mitbewerber McData übernahm. Das Unternehmen Cisco Systems, das ebenfalls die für die ILM-Strategie notwendige Netzwerk- und SAN-Infrastruktur bereitstellt, ist in Europa mit keinem nennenswerten Marktanteil im SAN-Umfeld vertreten und wird demzufolge hier nicht betrachtet. Interessant ist in diesem Abschnitt auch die Darstellung der Konzepte und Produkte der LSI-Logic Inc., die in Europa nicht direkt auf dem Markt für Speichersysteme auftritt, jedoch für einige der oben genannten Unternehmen das Equipment baut, das diese lediglich mit ihrem Namen und Logo versehen und als OEM der LSI Logic vertreiben. Letztendlich werden die Ansätze einiger Beratungshäuser und Integratoren kurz gestreift, so sie ihre Kunden überhaupt auf IM- und ILM-Projekte ansprechen. Die Beschreibung der von den Anbietern verfolgten Ansätze in Verbindung mit der erstellten Entscheidungstabelle gibt dem CIO, der Information Lifecycle Management einführen muss, das Instrumentarium in die Hand, sein ILM-Projekt erfolgreich mit den passenden Partnern zu initiieren und durchzuführen. Die in den beiden Bänden zugrunde liegende Auswahl der Inhalte entspringt zwar einer subjektiven Sicht der Dinge, beruht jedoch auf den langjährigen Erfahrungen der beiden Autoren in einschlägigen Projekten. Es besteht der Anspruch, sowohl einen Überblick über dieses beeindruckende Thema der derzeitigen IT-Landschaft zu liefern, als auch konkrete und einschlägige Projekterfahrungen aus Großprojekten weiterzugeben. Im Laufe dieses Buches werden eine Vielzahl von Firmen-, Produkt- und Methodennamen verwendet, deren Eigentümer zu nennen wir uns stets bemüht haben. Sämtliche Produkt-, Firmen- und Methodennamen sind Warenzeichen oder eingetragene Warenzeichen ihrer Eigentümer. Wir möchten die Einleitung mit Danksagungen an die Personen abschließen, mit denen wir Projekte realisierten, die uns erst in die Lage versetzten, das notwendige Know-how aufzubauen und zu verifizieren. Wir danken all unseren

Einleitung

XIII

Kollegen und Freunden, die die Entstehung des Buches aktiv unterstützt haben. Insbesondere möchten wir hier Armin Hochberger (BTC AG), Rudolf Kerber und Ralf Sczepanski (EMC2), Dieter Lohnes (HRES GmbH), Mario Vosschmidt (LSI), Georg Bonn, Ralf Aniol, Torsten Hannig, Franz-Josef Hellweg, Ulrich Kleineaschoff, Bettina Laue, Marco Münning, Peter Spanier (T-Systems Enterprise Services GmbH) nennen, die uns – bewusst oder unbewusst – eine Vielzahl wertvoller Hinweise im Rahmen der gemeinsamen einschlägigen Projekte gegeben haben, die in dieses Buch eingeflossen sind. Ebenso gilt der Dank Guido Hamacher (IC2IT), der viel Energie aufgewendet hat, weitere Informationen zu besorgen, die Versionen verwaltete und mit der notwendigen Akribie die erforderlichen Korrekturen durchführte. Fehler in diesem Buch sind jedoch die unseren und nur auf unser beschränktes Verständnis der wertvollen Hinweise und Erläuterungen von Zusammenhängen zurückzuführen. Wir danken den Hersteller- und Beratungsunternehmen, die uns als externen Consultants die Informationen zu ihrer ILM-Strategie mehr oder weniger bereitwillig verfügbar gemacht haben. Wir danken insbesondere auch unserem Verlag für die gute Betreuung und die unglaubliche Geduld mit zwei Autoren. Letztendlich danken wir den Menschen, die unzählige Stunden an Entbehrungen und Einschränkungen ihres und unseres gemeinsamen Lebens hinnehmen mussten, die nicht selbstverständlich sind – unseren Familien.

Aachen und Lienen im Februar 2007

Günter Thome und Wolfgang Sollbach

Inhaltsverzeichnis

1

Information als Produktionsfaktor und als Produkt ............................. 1.1 Information als Treibstoff von Produktion und Dienstleistung ... 1.2 Charakter der Information in Produktion und Dienstleistung.....

1 1 5

2

Information Lifecycle und Information Lifecycle Management........... 2.1 Anforderungen an das Informationsmanagement......................... 2.2 Der Informationslebenszyklus ......................................................... 2.3 Der Informationslebenszyklus-Strategien-Mix .............................. 2.4 Die Informationswert-Aufbewahrungszeit-Matrix ........................

15 15 22 30 54

3

Rechtliche Grundlagen des Information Lifecycle Management.......... 59 3.1 Information Lifecycle Management und Compliance ................... 59 3.2 Nationale (deutsche) Rechtsvorschriften ........................................ 61 3.3 Bindende europäische (Rechts-) Vorschriften................................ 87 3.4 International relevante US-amerikanische Rechtsvorschriften .... 91 3.5 Zertifikate, Prüfstellen und Standards............................................. 104 3.6 Information als Produktionsfaktor und Produkt sowie die relevanten juristischen Grundlagen........................................... 105

4

Schlüsselfaktor ILM-Modell........................................................................ 4.1 Die Bedeutung der Strategie ............................................................. 4.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle ....................................... 4.3 Strategische IT-Infrastrukturplanung ............................................. 4.4 Herausforderung für die strategische IT-Planung..........................

107 108

Strategische Einführungskonzepte für ILM ............................................. 5.1 ILM als Projekt ................................................................................... 5.2 SNIA-Stufenmodell............................................................................ 5.3 BITKOM-Prozessmodell ................................................................... 5.4 Strategische ILM-Prozessmodelle .................................................... 5.5 Aktuelle ILM-Trends ......................................................................... 5.6 Überprüfung der Voraussetzungen für ILM-Projekte.....................

145 145 146 149 150 155 156

5

111 113 137

XVI

Inhaltsverzeichnis

6

ILM aus Sicht des Projektmanagements ................................................... 6.1 Projektmanagement .......................................................................... 6.2 Projektcontrolling ............................................................................. 6.3 Projektsteuerung und Controlling................................................... 6.4 Projektrisikomanagement ................................................................

159 159 164 167 168

7

Schlüsselfaktor Klassifizierungskonzepte ................................................ 7.1 Fehlende Strukturierung................................................................... 7.2 Speicherklassifizierungskonzepte.................................................... 7.3 Generische Klassifizierungsansätze................................................. 7.4 Tiered Storage als Lösungsinstrument bei der operativen Umsetzung der Klassifizierung ........................................................

171 171 173 177

Schlüsselfaktor IT-Sicherheit...................................................................... 8.1 Datensicherheit.................................................................................. 8.2 IT-Speichersicherheit........................................................................ 8.3 Klassische Sicherheitskonzepte der zentralen Datenspeicherung.............................................................................. 8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung............................................................................ 8.5 Anforderung an die Organisation und die Betriebsführung......... 8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur .............. 8.7 Backup als Teil einer IT-Sicherheitsstrategie ................................. 8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie ............... 8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie ............. 8.10 Generelle IT-Sicherheitsanforderungen für ILM............................

193 193 195

9

Schlüsselfaktor Qualitätssicherung ........................................................... 9.1 Bedeutung des Qualitätsmanagements ........................................... 9.2 Qualitätsmanagement ....................................................................... 9.3 Qualitätssicherung im Rahmen des Projektmanagements............ 9.4 ILM-Qualitätssicherungsplanung .................................................... 9.5 Qualitätsziele...................................................................................... 9.6 Abnahmeprüfung .............................................................................. 9.7 Vorbeugende Qualitätssicherungsmaßnahmen ............................. 9.8 Projektbezogene Qualitätssicherung ...............................................

279 279 280 287 289 292 293 299 301

10

Schlüsselfaktor Risikomanagement........................................................... 10.1 Risikomanagement versus Qualitätsmanagements ....................... 10.2 Grundlagen des Risikomanagementprozesses ............................... 10.3 Risikomanagement vor dem Hintergrund der fehlenden internationalen Zertifikate und Standards für Compliance..........

311 311 313

8

190

198 202 216 226 236 244 257 276

321

Inhaltsverzeichnis

11

ILM vor dem Hintergrund der sich abzeichnenden Trends im globalen Wettbewerb und in der Informationstechnologie .................. 11.1 Herausforderung: Business Alignment............................................ 11.2 Herausforderung: IT-Sicherheit bei globaler Präsenz.................... 11.3 Antwort: Nutzung von IT-System- und IT-Netzmanagement ...... 11.4 Antwort: Nutzung einer Speichermanagementinfrastruktur........ 11.5 Antwort: Nutzung von Security Management Tool........................ 11.6 Antwort: Nutzung des SAN- und NAS-Switch-Managements ...... 11.7 Antwort: Nutzung verbesserter Methoden beim SAN-Zoning und beim LUN-Masking.................................................................... 11.8 Antwort: Nutzung der Grid- bzw. Virtualisierungstechnologie.... 11.9 Antwort: Nutzung des Online-Datenschutzes für Backup und Disaster Recovery.......................................................................

XVII

323 323 325 327 330 331 336 338 340 342

ILM Projektmanagement í Kurzbeschreibung Organisation und Struktur .................................................................................................. 12.1 Projektkurzbeschreibung.................................................................. 12.2 Anforderungen an das Projektmanagement ................................... 12.3 Aktivitäten der Startphase ................................................................ 12.4 Aktivitäten über die komplette Projektlaufzeit ..............................

345 346 347 350 356

Index ........................................................................................................................

367

12

1 Information als Produktionsfaktor und als Produkt

1.1 Information als Treibstoff von Produktion und Dienstleistung 1.1.1 Anforderungen an das Information Lifecycle Management (ILM) Märkte und Technologien die sich mit der Speicherung und Verwaltung von Dokumenten bzw. Informationen beschäftigen, befinden sich aktuell in einem dramatischen Umbruch um den gestiegenen Anforderungen gerecht zu werden, denn die Datenbestände von Unternehmen wachsen kontinuierlich. Die Bedeutung der zielgerichteten Speicherung und der zielgerichteten Bereitstellung von Information steigt in allen volkswirtschaftstheoretischen Sektoren, d. h. sowohl im primären (Rohstoffgewinnung und -verarbeitung), im sekundären (industrielle Produktion) als auch insbesondere im tertiären Sektor (Dienstleistungen). Im Zeitalter des E-Business wurden zudem zahlreiche weitere neue Applikationen entwickelt. Neben ERP-Systemen gibt es heute zunehmend in Unternehmen auch Customer Relationship Management (CRM), Data-Warehouse-Systeme und Data Warehouse Bus für den universellen „Abgriff“ von Daten sowie Supply Chain Management (SCM), um nur die wichtigsten zu nennen. Diese Applikationen zeichnen sich nicht nur durch ihre Bedeutung für den geschäftlichen Erfolg für die Unternehmen aus, sie haben auch einen enormen Bedarf an Speicherressourcen, der ständig weiter ansteigt. Die IT-Abteilung eines durchschnittlichen Unternehmens hat pro Jahr einen Bedarf an neuem Speicher von 5070 Prozent des bestehenden Speichervolumens. Alte Daten können zudem nicht einfach gelöscht werden, da es zahlreiche gesetzliche Bestimmungen gibt, zu deren Erfüllung umfangreiche Archive angelegt werden und Daten jederzeit verfügbar sein müssen. Gleichzeitig liegt ein wachsender Kostendruck auf den IT-Abteilungen. Umso wichtiger wird ein einheitliches und dabei kostensensitives Datenmanagement, welches die richtigen Daten zum richtigen Zeitpunkt dort verfügbar macht, wo sie aktuell benötigt werden. In den letzten Jahren hat sich in diesem Umfeld ILM als probates Konzept etabliert, um den Anforderungen der modernen Datenspeicherung zu begegnen. Nur im engeren Sinne handelt es sich bei ILM um ein Speichermanagementkonzept, das Informationsobjekte während

2

1 Information als Produktionsfaktor und als Produkt

der gesamten Lebenszeit auf der Basis eines Regelwerkes aus Prozessen und Technologie aktiv verwaltet. Business Intelligence (BI) benutzt dieselben Informationsobjekte, um ein Unternehmen durch Kenntnis der Geschäftsprozesse und deren Wirkungszusammenhänge operativ und strategisch zu führen. Obwohl bereits eine Reihe von ILM-Konzepten eine Klassifizierung der Daten vorsehen, ist eine Integration der Bedürfnisse aus BI-Sicht bislang noch nicht erfolgt. Diese Daten sind jedoch aus Unternehmenssicht zentral, da die Planung und die Steuerung des Unternehmens wesentlich von verfügbaren und korrekten operationellen Daten abhängen. Die Sicherstellung dieser Daten mittels eines durchgängigen ILM-Konzeptes ist nur dann möglich, wenn BI-Anforderungen bereits in die Datenklassifizierung einfließen. Ohne Einbeziehung der Bedürfnisse der Unternehmenssteuerung ist das Konzept unvollständig. Aktuell sind die meisten Unternehmen noch damit beschäftigt, die Voraussetzungen für die Umsetzung zu schaffen. Dennoch ist es sinnvoll, bereits heute über die Bewertungskriterien nachzudenken, um die Grundlagen für eine aktive Verwaltung der Unternehmensdaten über ihre ganze Lebenszeit hinweg zu schaffen. Aktuelle ILM-Modelle unterscheiden in ihren Konzepten nicht zwischen operationellen und nicht operationellen Daten. Diese Unterscheidung ist jedoch für den Bereich Business Intelligence (BI) zentral. Die Informationen, die in Business-Performance-Management (BPM)-Systemen gehalten werden, bestimmen den Unternehmenswert maßgeblich. Heute existiert jedoch keine einheitliche BI-Systemarchitektur, die zu einem integrierten Datenmodell von Data Warehouses (DW) und der Vielzahl von Tabellen- und Berichtsdokumenten führen könnte. Die Klassifizierung von Informationsobjekten sollte also nicht nur aus Sicht der regulatorischen Vorgaben und der Speicherkosten erfolgen. Darüber hinaus sind Kriterien einzuführen, die die Bedürfnisse von BI abdecken. So sind sowohl die operationellen Daten wie auch Data Warehouses mit allen zur Entscheidungsunterstützung verwendeten Informationsobjekten entsprechend zu klassifizieren und innerhalb eines ILM-Konzeptes zu behandeln. Im Idealfall hat ein Unternehmen eine durchgängige BI-Architektur umgesetzt. Die operativen Daten werden über Data Warehouses verdichtet, die zusammengefasst sämtliche für die Steuerung eines Unternehmens relevanten Informationen, Funktionen und Prozesse enthalten. Leider haben die wenigsten Unternehmen eine BI-Architektur realisiert, die sämtliche planungs- und entscheidungsrelevanten Informationen enthält. So werden Verträge durch E-Mail bestätigt, Excel-Tabellen enthalten Finanzdaten, Investitionsanträge und Entscheidungsprotokolle (und deren Input) sind als Word-Dokument abgelegt, die entsprechenden Arbeitsaufträge werden wiederum per E-Mail an die Mitarbeiter gegeben. All diese Informationen sind in keinem Data Warehouse abgespeichert. Sie sind jedoch zentral für die Steuerung eines Unternehmens. Um wettbewerbsfähig zu bleiben, muss der Produktionsfaktor Information systematisch gestärkt und effizient genutzt werden. Ein Viertel der täglichen Arbeitszeit verbringt jeder Beschäftigte im administrativen Bereich im Schnitt mit der Suche nach Informationen, und oft genug ist

1.1 Information als Treibstoff von Produktion und Dienstleistung

3

die Suche vergeblich. Wer kennt nicht die Situation, in der ein Mitarbeiter nicht erreichbar ist und seine Kollegen sehr zeitaufwendig versuchen, die Daten eines Angebots zu rekonstruieren, die irgendwo abgelegt wurden. Im Zweifelsfall liegen sie auf der Festplatte im Notebook des Mitarbeiters. In gleicher Weise führt die aus Kostengesichtspunkten notwendige Limitierung der Größe des E-Mail-Accounts regelmäßig dazu, dass Mitarbeiter ihre eigene lokale Ablage aufbauen, die zeitaufwendig gepflegt wird. Teilweise sind die Mitarbeiter damit ganze Arbeitstage beschäftigt. Zudem wird bei fast jedem Releasewechsel eine zeitaufwendige Rekonfiguration durchgeführt. Diese Situationsbeschreibung ist immer noch der Normalzustand, der selbst bei führenden Speichersystemanbietern anzutreffen ist, wie die beiden Autoren aus langjährigen, leidvollen Erfahrungen bestätigen können.

1.1.2 Leistungsdimensionen zur Beschreibung der Bedeutung von Information Im Gegensatz zur betrieblichen Praxis findet die Bedeutung der zielgerichteten Bereitstellung von Information in den volkswirtschaftstheoretischen Erklärungsansätzen des primären, des sekundären und insbesondere des tertiären Sektors keine entsprechende Berücksichtigung. Im neoklassischen Marktverständnis stellt die Unternehmung ein Input-Output-System dar, dessen Aufgabe die Gewinnmaximierung unter der Nebenbedingung der Produktionsfunktion ist. In seinem faktortheoretischen Ansatz geht Gutenberg von vollkommenen Faktormärkten aus. Die originäre Aufgabe der Geschäftsleitung (dispositiver Faktor) ist dabei die Disposition über Elementfaktoren, zu der die Information als solches nicht gehört. Die „Neue Institutionsökonomik“ geht davon aus, dass Individuen versuchen, durch ihre Handlungen ihren Nutzen zu maximieren. Dabei lässt diese explizit unterschiedliche Interessen der Handelnden zu. Das Handeln der Wirtschaftssubjekte beruht auf unvollkommenen Informationen. Unvollkommene Informationen begründen Unsicherheit im Handeln. Erst die „Neue Institutionsökonomik“ begreift Information als einen notwendigen Input, der nicht kostenlos zur Verfügung steht.9 Die Bewältigung von durch Marktprozesse verursachten Unsicherheiten ist zentraler Gegenstand des strategischen Managements. Die Vielzahl der Paradigmen des „Strategischen Managements“ vom Rationalismus/Kognitivismus (Gutenberg), „Probabilismus-Paradigma“, „Verhaltenswissenschaftlicher Ansatz“ (Macharzina), „Ökonomische Ansätze“ (Erlei/Leschke/Sauerland), „Determinismus-Paradigma“, „Industrieökonomik“, „Population-Ecology Ansatz, „Entwicklungsparadigma“ bis zum „Chaos-Paradigma“ und der „Postmodernen“ fassen Management als Bewältigung von Unsicherheit auf. Zentral ist die Annahme, dass die Unternehmensleitung mittels gedanklicher (kognitiver) Strukturierung  9

Vgl. Richter, Rudolf, Grundtvig, Erik: Neue Institutionsökonomik 1999; Mohr, Siebek, aus www.grin.com.

4

1 Information als Produktionsfaktor und als Produkt

die komplexe und unsichere Umwelt durchdringen und eindeutige Handlungsempfehlungen für die Bewältigung der Managementaufgaben entwickeln kann. Diese Sichtweise findet sich in den ingenieurmäßig-ökonomischen Ansätzen des „Scientific Management“ von Taylor und des „Industrial Engineering“, in den administrativen Ansätzen sowie im „Bürokratie Ansatz“ von Max Weber. Gleichwohl ist der Schwerpunkt der verschiedenen Ansätze der industrielle Produktionsprozess. Aus Sicht von Albachs „Theorie der industriellen Dienstleistungen“ führt der Angebotsdruck im industriellen Sektor jedoch zu einem steigenden Dienstleistungsanteil.10 Der Nutzen des Produktes wird dadurch gesteigert, dass zusätzlich zum Produkt sog. produktbegleitende Dienstleistungen angeboten werden. Mehr und mehr Beschäftigte im primären und im sekundären Sektor erbringen Dienstleistungen. Dabei wird die Besonderheit von Dienstleistungen darin gesehen, dass der Dienstleister sich auf die Vermarktung des Leistungspotenzials, d. h. der Bereitschaft und Fähigkeit zur Erbringung einer Leistung, konzentrieren muss.11 Im Gegensatz zu so genannten Sachleistungen, die auch auf Lager produziert werden können und meist bereits vor der Vermarktung als „fertige Produkte“ vorhanden sind, stellen Dienstleistungen lediglich Leistungsversprechen dar, mit deren Konkretisierung erst nach Vertragsabschluss begonnen werden kann. Aufgrund des unterschiedlichen Charakters zwischen der industriellen Güterproduktion und den Dienstleistungen schlägt Corsten eine Unterteilung des Produktionsfaktorsystems in ein Grundsystem, das für alle Branchen und Bereiche Gültigkeit besitzt, und branchenspezifische Module vor.12 Das Grundsystem besteht wiederum aus zwei Subsystemen, den internen Produktionsfaktoren und den externen Faktoren, die vom Nachfrager bereitgestellt werden. Insbesondere im Hinblick auf die Abgrenzung von Dienstleistungen und Sachleistungen wird diskutiert, ob es sich bei der Information um einen externen Faktor handelt oder nicht.13 Dabei wird zwischen Potenzialinformationen und externen Prozessinformationen unterschieden, wobei die externen Prozessinformationen solche Informationen beschreiben, die der Nachfrager während des Leistungserstellungsprozesses zur Verfügung stellt. Unter Potenzialinformationen versteht man demgegenüber solche Informationen, die der Anbieter unabhängig von konkreten Markttransaktionen beschafft.14 Sowohl Potenzialinformationen als auch externe Prozessinformationen sind dadurch gekennzeichnet, dass sie zweckorientiertes Wissen darstellen und dass es sich im Sinne von Gutenberg um Verbrauchsfaktoren handelt. Das Paradigma der „Information als Verbrauchsfaktor“ sieht in der Information nur den Zweck, dazu beizutragen, dass ein anvisiertes Ziel erreicht wird. Der Verbrauchsfaktor Informationen ist dann verbraucht, wenn das Ziel erreicht  10 11 12 13 14

Albach, H.: Organisation: Mikroökonomische Theorie und ihre Anwendungen, Wiesbaden, 1989. Meyer-Stamer, Jörg: Strategien lokaler/regionaler Entwicklung, Projekt Meso-NRW, 1993. Corsten, H.: Die Produktion von Dienstleistungen, Berlin, 1985. Corsten, H.: Dienstleistungsmanagement, München, 1997. Kleinaltenkamp, M.: Begriffsabgrenzungen und Erscheinungsformen von Dienstleistungen, in: Bruhn, Stauss (Hrsg.), Handbuch Dienstleistungsmanagement, 2002.

1.2 Charakter der Information in Produktion und Dienstleistung

5

wurde. Informationen verbrauchen sich also nicht durch Veränderung oder Verstreichung der Zeit, sondern auch weil sich die Umstände ändern können, die aus Wissen Information machen. Obwohl die obigen produktionswirtschaftlichen Grundmodelle der industriellen Produktion und der Dienstleistungserstellung noch nicht alt sind, werden wesentliche Aspekte der betrieblichen Praxis nicht ausreichend berücksichtigt. Der einzelne Nachfrager stellt für die betriebliche Leistungserstellung externe Prozessinformationen zur Verfügung, mit deren Hilfe er in den Leistungserstellungsprozess eingreift und ihn steuert. Durch den Kontakt zum Anbieter während des Leistungserstellungsprozesses ist der Nachfrager ebenfalls in einen Prozess der Informationsgewinnung eingebunden. So fließen ihm Informationen verschiedenster Art zu. Die Informationen über das Leistungspotenzial, den Leistungserstellungsprozess und das Leistungsergebnis bzw. seine Teilergebnisse stellen für den Nachfrager zunächst nur Daten dar. Im Zuge ihrer Aufbereitung und Speicherung können sie aber das Wissensreservoir des Nachfragers anreichern und im Rahmen seines Leistungspotenzials weiter genutzt werden. So kann der Nachfrager aus dem Verlauf des Leistungserstellungsprozesses und den Informationen über das Leistungspotenzial des Anbieters Anregungen bezüglich der Gestaltung seiner eigenen internen Prozesse gewinnen. Das im eigenen Leistungsprozess aktivierte Wissen steuert als externe Prozessinformation dann einen neuen Leistungserstellungsprozess. Jeder Leistungserstellungsprozess wird somit durch die Integration zumindest von Information angestoßen. Dies erfolgt unabhängig davon, ob auch eine technische Integration der vom Nachfrager zur Verfügung gestellten Objekte stattfindet, und unabhängig davon, in welchem Umfang der Nachfrager raumzeitlich während des Leistungserstellungsprozesses anwesend sein muss. Insbesondere für die immer stärker von den Nachfragern geforderte Individualisierung des Leistungsergebnisses ist dabei die Integration von Information ausschlaggebend. Dies gilt auch für die Qualität des Leistungsergebnisses. Information ist damit mehr als ein Verbrauchsfaktor. Information ist vielmehr der Treibstoff der heutigen betrieblichen Produktion und der Dienstleistungserstellung.

1.2 Charakter der Information in Produktion und Dienstleistung 1.2.1 Information als Produktionsfaktor Postulieren wir die Information als Produkt und Produktionsfaktor, so betrachten wir Information als marktbeeinflussendes Moment, ja Element. Sowohl als Produkt wie auch als Produktionsfaktor muss Information selbst einen Markt besitzen. Nähern wir uns also der Information aus betriebswirtschaftlicher Richtung, hinterfragen den Produktcharakter und betrachten den Markt des Produktes Information. Gelingt es uns, den Produktcharakter der Information zu

6

1 Information als Produktionsfaktor und als Produkt

begründen, wird die Argumentationskette des Buches aus betriebswirtschaftlicher Sicht einfach und lässt sich mit betriebswirtschaftlicher Methodik prüfen. Folgen wir daher zunächst den betriebswirtschaftlichen Definitionen für Produkt, Produktionsfaktor und Markt und suchen, die Gültigkeit der Definition auch für Information abzuleiten. Den klassischen Einführungswerken in die Betriebswirtschaftslehre folgend, stellt man überrascht fest, dass der Begriff des Produktes undefiniert bleibt, auch wenn er in vielfältigen semantischen Kombinationen per se verwendet wird. Das Produkt bleibt ein undefiniertes Synonym für Gut, Wirtschaftsgut und anbieterseitiges Aktionsergebnis des Wirtschaftens, das als Produzieren oder Produktion bezeichnet wird.15 Folgen wir der Definition gemäß Wikipedia (vgl. Abb. 1.1) und beschreiben ein Produkt als Resultat einer Fertigung (Synonym für Produktion) oder als eine angebotene Dienstleistung und definieren wir Produktion als Prozess der betrieblichen Leistungserstellung, so subsumiert die Produktion: a) die Gewinnung von Rohstoffen in Gewinnungsbetrieben; b) die Herstellung von Erzeugnissen in Fertigungsbetrieben; c) die Bearbeitung von Rohstoffen und Fabrikaten in Veredelungsbetrieben; d) die Ausführung von Dienstleistungen durch Dienstleistungsbetriebe.16 „Der Begriff Produktion umschließt dann folgende Grundfunktionen: Beschaffung, Transport, Lagerhaltung und Fertigung, ferner Verwaltung und Kontrolle dieser Bereiche.“17 Basierend auf diesen Definitionen ist Information ein Ergebnis eines betrieblichen Leistungserstellungsprozesses. Informationen werden beschafft, transportiert, als „Datum“ gespeichert (Lagerhaltung) und produziert. Das Informationsmanagement als Verwaltung und Kontrolle dieses Prozesses definiert zusätzlich die Information als Produkt. Diederich unterteilt Produktionsfaktoren in Betriebsmittel, Leistungsobjekte und (menschliche) Arbeit. Betriebsmittel sind danach „diejenigen sachlichen Faktoren […], die von den Menschen im Betrieb zu ihrer Unterstützung bei der Leistungserstellung herangezogen werden.“18 Zu ihnen zählen auch die gesamte technische Apparatur sowie die Betriebsmittel. Leistungsobjekte sind „die Gegenstände des Tätigwerdens von Menschen und Betriebsmitteln, also Objekte des Leistungserstellungsprozesses. […] Für einzelne Betriebsarten ist allerdings noch nicht abschließend erörtert, welches die Leistungsobjekte sind; es erscheint sogar möglich, dass es Betriebe gibt, in denen Leistungsobjekte im definierten  15

16

17 18

Diederich, Helmut: Allgemeine Betriebswirtschaftslehre I, Stuttgart, Berlin, Köln, Mainz, 1979, S. 18. und Wöhe, Günter: Einführung in die Allgemeine Betriebswirtschaftslehre, 13. Aufl., München, 1978, S. 287. Gutenberg, E.: Grundlagen der Betriebswirtschaftslehre, Bd. 1: Die Produktion, 21. Aufl., Berlin, Heidelberg, New York, 1975, S. 1 f. nach Wöhe, Günter, a.a.O., S. 287. Wöhe, Günter, a.a.O., S. 287. Diederich, Helmut, a.a.O., S. 139.

1.2 Charakter der Information in Produktion und Dienstleistung

7

Sinne fehlen.“19 Der Produktionsfaktor Arbeit unterteilt sich in objektbezogene und dispositive Arbeit. Objektbezogene Arbeit hat ausführenden Charakter. Das kreative Moment der Arbeit, die Kombination von Betriebsmitteln, Leistungsobjekten und objektbezogener Arbeit, wird als dispositive Arbeit bezeichnet.20 Legt man diese betriebswirtschaftliche Definition der Produktionsfaktoren zugrunde, so kann in der heutigen Informationsgesellschaft die Information klassisch als Betriebsmittel betrachtet werden. Für eine Vielzahl von Dienstleistungsunternehmen sowie insbesondere für die komplette Bandbreite von Unternehmen aus dem Finanzsektor ist Information als Leistungsobjekt zu verstehen. Aus diesen Betrachtungen wird der bivalente Charakter der Information als Produktionsfaktor und als Produkt klar ersichtlich. Setzt man Information gleich mit Wissen, so wird in betriebswirtschaftlicher Literatur heute Wissen als vierter Produktionsfaktor definiert, so dass auch aus diesem Ansatz der Charakter der Information sowohl als Produkt als auch als Produktionsfaktor klar hervortritt.21 Wie sieht der Markt für das Produkt/den Produktionsfaktor Information aus? „Das Marktmodell beschreibt die Abstimmung entgegen gerichteter Interessen von Wirtschaftssubjekten beim Tausch bzw. Kauf und Verkauf. […] Stets geht es […] um die Bestimmung von Preis und Absatzmenge bzw. den Ausgleich von Angebot und Nachfrage. Markt ist dabei der ökonomische Ort des Aufeinandertreffens von Angebot und Nachfrage.“22 Märkte werden in vollkommene und unvollkommene Märkte untergliedert. Die Merkmale eines vollkommenen Marktes sind dabei: „(1) sachliche Gleichartigkeit (Homogenität und Fungibilität) der Güter; (2) Nichtvorhandensein persönlicher Präferenzen von Käufern für bestimmte Verkäufer et vice versa; (3) Nichtvorhandensein räumlicher Differenzierungen zwischen den einzelnen Anbietern bzw. Nachfragern; (4) Nichtvorhandensein zeitlicher Differenzierungen zwischen den einzelnen Anbietern bzw. Nachfragern; (5) vollständige Markttransparenz.“23 Unvollkommene Märkte zeichnen sich durch die Verletzung eines der ersten vier Kriterien des vollkommenen Marktes aus. Temporär ist ein Markt unvollkommen, wenn die ersten vier (Homogenitäts-) Bedingungen zwar erfüllt, die Markttransparenz jedoch nicht gegeben ist. Allgemein wird in Volks- und Betriebswirtschaftslehre davon ausgegangen, dass es keine vollkommenen Märkte gibt. Ein Beispiel für ein Produkt, für das es  19 20 21

22 23

Diederich, Helmut, a.a.O., S. 139. Diederich, Helmut, a.a.O., S. 139 f. Vgl. Probst, G., Raub, S., Romhardt, K.: Wissen managen, 3. Aufl., Wiesbaden, 1999. Vgl. auch Steward, Th.: Der vierte Produktionsfaktor, München, Wien, 1998. Bartmann, Hermann: Preistheorie (Vorlesung), St. Gallen, 1981, S. A/1. Ott, Alfred E.: Preistheorie, in: Ehrlicher, W. et al.: Kompendium der Volkswirtschaftslehre, 5. Aufl., Göttingen, 1975, S. 119.

8

1 Information als Produktionsfaktor und als Produkt

Abb. 1.1. Definitionen nach Wikipedia24

eventuell doch einen vollkommenen Markt gibt, ist die Information. Information erfüllt prinzipiell die ersten vier – auch als Homogenitätsbedingungen bezeichneten – Charakteristika des vollkommenen Marktes. Mit dem explosionsartigen Aufschwung des World Wide Web scheint hier auch die Bedingung der vollständigen Markttransparenz erfüllt zu sein. Ja es sind sogar legislative Maßnahmen erforderlich, die Markttransparenz des Informationsmarktes einzuschränken. Regelungen durch beispielsweise das Bundesdatenschutzgesetz und das BSI sind nichts anderes als eine Reglementierung der Transparenz des Informationsmarktes. Zusammenfassend kann festgehalten werden, dass Information insbesondere aus betriebswirtschaftlicher Sicht sowohl ein Produkt als auch einen Produktionsfaktor darstellt und es sehr wohl einen Markt für dieses Produkt gibt.

1.2.2 Der Informationsproduktlebenszyklus Der Produktlebenszyklus orientiert sich an der zeitlichen Entwicklung des Absatzes eines Produktes. Der Zeitraum zwischen Markteintritt und Ausscheiden

 24

Vgl. http://de.wiktionary.org/wiki/Information; http://de.wiktionary.org/wiki/Markt; http://de.wiktionary.org/wiki/Produkt; http://de.wiktionary.org/wiki/produzieren.

1.2 Charakter der Information in Produktion und Dienstleistung

9

aus dem Markt wird als der Lebenszyklus eines Produktes definiert.25 Mit dem Produktlebenszyklus wird der Bedeutung der Nachfrageentwicklung im Zeitablauf für die Absatzplanung Rechnung getragen. Das Grundmodell des Produktlebenszyklus betrachtet dabei, differenziert nach in der Regel Umsatzzahlen und deren Entwicklung, zeitlich aufeinander folgende Phasen: Das Produkt wird auf seinem Lebensweg mit phasenkonformen Marketingmaßnahmen unterstützt. In der Einführungsphase hat das Produkt in der Regel mit Kaufwiderständen zu kämpfen, denen mit Werbung, PR-Maßnahmen und eventuell einer aggressiven Preispolitik begegnet wird. Der Erfolg dieser Maßnahmen bewirkt das Überleben des Produktes. Klassische Kunden in dieser Phase sind Innovatoren, die stets am Puls der Zeit agieren. In der Wachstumsphase ist das Produkt prinzipiell am Markt eingeführt und akzeptiert. Der Umsatz steigt ohne zunehmende Marketinganstrengungen. Das Produkt hat seine Marktfähigkeit bewiesen, was Konkurrenten auf den Plan ruft, Nachahmerprodukte auf den Markt zu bringen. Hier ist nun eine behutsame Preispolitik gefragt, um die Konkurrenz möglichst vom Markt fernzuhalten. Marktkommunikation hat in der Phase des schnellen Wachstums eine katalytische Funktion und beschleunigt den Umsatz des Produktes. Kunden dieser Phase sind die so genannten Early Adopters, die – vertrauend darauf, dass die Innovatoren die Kinderkrankheiten des Produktes erkannt und auf deren Beseitigung gedrängt haben – nun Skaleneffekte durch dieses Produkt erwarten. Ein Produkt hat seine Reifephase erreicht, wenn der Umsatz respektive dessen Wachstum am Markt stagnieren. Das Produkt ist hier zum Gemeingut, idealerweise zur Marke geworden, ein Produkt, das man eventuell haben muss. In dieser Phase wird in der Regel ein namensbezogenes Erhaltungsmarketing betrieben, um die Reifephase des Produktes so weit als möglich auszudehnen, da diese meist die ertragreichste Phase im Produktlebenszyklus darstellt. Weiter ist dies die Phase, in der Produktänderungen stattfinden, die auch bei bewährten Produkten eine innovative Wahrnehmung bewirken sollen. Ein schönes Beispiel für dieses Verhalten der Anbieter in der Reifephase ihres Produktes mag sein, dass ungefähr zur Hälfte der Modelllebenszeit jeder Automobilhersteller seine Modelle nochmals grundlegend überarbeitet und zumindest mit Designänderungen aufwartet. Kunde dieser Phase ist die breite Masse, die auf Bewährtes setzt. Die Sättigungsphase wird dadurch gekennzeichnet, dass der Markt von dem Produkt so durchdrungen ist, dass „jeder das Produkt bereits hat“. Als Beispiel mag der Markt für Mobiltelefone dienen. Das Produkt wird lediglich noch dann nachgefragt, wenn es ersetzt werden muss (technische Lebensdauer des Produktes überschritten), durch die demografische Entwicklung neue Käufer hinzukommen (Jugendliche) oder eine neue Mode die Nachfrage des Produktes anregt. Hier werden die Aktivitäten zur Produktdiversifikation verstärkt, die bereits zur Reifephase gestartet wurden.  25

Diederich, Helmut: Allgemeine Betriebswirtschaftslehre II, Stuttgart, Berlin, Köln, Mainz, 1979, S. 113 ff.

10

1 Information als Produktionsfaktor und als Produkt

Abb. 1.2. Grundmodell des Produktlebenszyklus

Die Degenerationphase des Produktes ist erreicht, wenn erkennbar ist, dass das Produkt vom Markt verschwinden wird. Der Absatz des Produktes geht irreversibel zurück, Kunden sind lediglich noch Nachzügler. Das Produkt sollte jedoch erst dann vom Markt eliminiert oder durch einen Relaunch abgelöst werden, wenn es keinen positiven Deckungsbeitrag mehr liefert. Dieses Grundmodell des Produktlebenszyklus gilt prinzipiell für sämtliche Produkte mit Ausnahme einiger weniger Produktkategorien wie beispielsweise Grundnahrungsmittel. Die Entwicklung des Absatzes solcher Produkte hängt im Wesentlichen nur von der demografischen Entwicklung ab. Dennoch haben sich im Laufe der Zeit charakteristische Produktlebenszyklusmuster (spezielle Produktlebenszyklen) unterschiedlicher Produkte und Produktkategorien entwickelt. So unterscheidet Zingel beispielsweise das Wachstums-Einbruch-ReifeMuster für Küchengeräte, das Zyklus- und Erneuerungsmuster für Medikamente und stark beworbene Konsumgüter, das Kerbschnittmuster für Produkte mit sich zyklisch erschließenden Produkteigenschaften sowie Schwankungsmuster bei Stilepochen und Modeprodukten.26 Die Autoren werden den Information Lifecycle als speziellen Produktlebenszyklus des Produktes und vierten Produktionsfaktors Information beschreiben. Die phasenbezogenen Maßnahmen werden als Information Lifecycle Management (ILM) betrachtet.  26

Zingel, Harry: Produktlebenszyklus und strategisches Marketing, Skript für Zwecke der Aus- und Fortbildung, Version 3.00, 1996-2003, www.zingel.de.

1.2 Charakter der Information in Produktion und Dienstleistung

Abb. 1.3. Phasen des Produktlebenszyklus27

Abb. 1.4. Strategien im Marketing-Mix28

 27 28

Kotler, Philip, Bliemel, Friedhelm: Marketing Management, Stuttgart, 1995, S. 586. Kotler, Philip, Bliemel, Friedhelm, a.a.O., S. 586.

11

12

1 Information als Produktionsfaktor und als Produkt

1.2.3 Portfolioanalyse Die Portfolioanalyse betrachtet die Entwicklung eines Produktes respektive eines Produktportfolios hinsichtlich diverser Parameter innerhalb dessen Lebenszyklus. Die wohl bekannteste Visualisierung einer Portfolioanalyse stellt das Vier-Felder-Portfolio (Marktanteil-Marktwachstums-Matrix, Boston Consulting Group Portfolio) dar. Hier werden Marktanteil und Marktwachstum eines Produktportfolios innerhalb seines Lebenszyklus in Relation gesetzt. Im Vier-Felder-Portfolio wird das Produktportfolio in vier Segmente aufgeteilt und eine optimale Produktverteilung empfohlen. Bereits im vorigen Abschnitt haben wir über die unterschiedlichen Strategien im Marketing-Mix, bezogen auf die Phasen des Produktlebenszyklus reflektiert. Hier können diese auf die unterschiedlichen Segmente des Produktportfolios herunter gebrochen werden. Die Problem Children dienen der strategischen Absicherung der Zukunft des Unternehmens. Sie zeichnen sich durch einen (noch) geringen Marktanteil, jedoch eine hohe Wachstumsrate aus. Der geeignete Mix aus Produkt-, Preisund Distributionspolitik sowie Werbung, Kommunikation und Verkaufsförderung für die Einführungs- und Wachstumsphase sollen Bekanntheitsgrad und Marktanteil der Produkte heben. Ziel ist es, die Nachwuchsprodukte, deren Zukunft noch ungewiss ist, in das Segment der Stars zu heben. Mindestens

Abb. 1.5. Das Vier-Felder-Portfolio

1.2 Charakter der Information in Produktion und Dienstleistung

13

10 Prozent der vom Unternehmen angebotenen Produkte sollten dem Segment der Problem Children angehören. Die Stars sind die Produkte, die den Haupterfolg des Produktportfolios darstellen. Sie haben noch immer hohe Wachstumsraten bei hohem Marktanteil. Für diese Produkte gelten die Strategien der Reife- und Sättigungsphase des Produktlebenszyklus im Marketing-Mix. Ziel muss sein, die hohen Marktanteile und die Wachstumsdynamik so lange als möglich aufrechtzuerhalten. Innerhalb des Produktportfolios eines Unternehmens sollten ca. 30 Prozent dem Segment der Star-Produkte angehören. Cash Cows sind die Produkte im Produktportfolio, die bei hohem Marktanteil und geringem Wachstum in der Reifephase/Sättigungsphase des Produktlebenszyklus positive Deckungsbeiträge erwirtschaften. Hier gilt es ebenfalls, die Strategien des Marketing-Mix der Reife- und Sättigungsphase zu wählen und die Erträge auf dem Markt abzuschöpfen. Außerdem sind hier Marketingmaßnahmen auf kurzfristige Aktionen beschränkt, da dem Produkt in seiner derzeitigen Form keine große Zukunft mehr beschieden ist. Ca. 4050 Prozent der Produkte im Portfolio sollten Cash Cows sein. Auf die Produkte im Segment der Dogs werden die Strategien des MarketingMix der Degenerationsphase des Produktlebenszyklus angewendet. Sie bleiben nur noch so lange im Portfolio, wie sie einen positiven Deckungsbeitrag erwirtschaften. Diese Auslaufprodukte sollten einen Anteil von maximal 20 Prozent im Produktportfolio eines Unternehmens bilden. Das hier geschilderte Vier-Felder-Portfolio ist das einfachste auf dem Produktlebenszyklus basierende Verfahren der Portfolioanalyse. Eine Vielzahl weiterer Portfolios wurde als Erweiterung des Vier-Felder-Portfolios (beispielsweise Neun-Felder-Portfolio), als Kundenattraktivitäts-Lieferantenpositions-Portfolio (Kundenportfolio) usw. entwickelt. Diese sowie weitere Portfolioanalysen zur Produktionsprogrammplanung wie die Ansoff-Matrix zum Produkt-MarktPortfolio wollen wir hier nicht darstellen, da dies am Thema des Buches vorbeigehen würde. Hierzu verweisen wir auf die einschlägige Literatur zu Marketing, Investitionsgütermarketing und Konsumgütermarketing. Unsere Absicht ist es, basierend auf dem betriebswirtschaftlichen Ansatz des Produktlebenszyklus den Information Lifecycle als speziellen Lebenszyklus der Information darzustellen, das Information Lifecycle Management als phasenbezogenen Strategien-Mix zu beschreiben und dieses zur Grundlage der Portfolioanalyse der Informationen eines Unternehmens in einer Informationswert-Aufbewahrungszeit-Matrix für das Informationsmanagement heranzuziehen.

2 Information Lifecycle und Information Lifecycle Management

2.1 Anforderungen an das Informationsmanagement Der Weg der Gesellschaft von einer industrialisierten zu einer Informationsund Dienstleistungsgesellschaft stellt die „Informationsverantwortlichen“ der Unternehmen vor neue Herausforderungen. War IT in ihren Anfängen zuvorderst vor allem Informationssammlung und Informationsverarbeitung, so war sie in der vergangenen Dekade geprägt durch Verfahren, die gesammelten Informationen zur Verarbeitung wiederzufinden und zu verdichten. Der beschriebene Einsatz von Customer Relationship Management (CRM-) Softwaresystemen, Enterprise Ressource Planning (ERP-) Systemen sowie Data Warehouse (DW) in Verbindung mit Data-Mining-Verfahren und intelligenten Strukturierungen als „Bus“ für den universellen „Abgriff“ von Daten sind die IT-technischen Ausprägungen dieser Aufgabenstellung. Jedoch, Informationsmanagement wird aufgrund der unmäßigen Sammlung von Informationen vor neue Aufgaben und Herausforderungen gestellt. Hier fällt allein schon in der begrifflichen Terminierung ein häufig verwirrendes Durcheinander zwischen Daten und Informationen auf. Diese beiden Begriffe werden gerne synonym verwendet: „Die Informatik und Datenverarbeitung (EDV) benutzen Daten als (maschinen-) lesbare und bearbeitbare Repräsentation von Information. Die Information wird dazu in Zeichen (bzw. Zeichenketten) codiert, deren Aufbau strengen Regeln folgt, der so genannten Syntax. Daten werden zu Informationen, wenn sie in einem Bedeutungskontext stehen.“ 9 Das unnachgiebige Wachstum der Informationsmengen mag sich an der Steigerung des Kapazitätsbedarfes an Festplattenplatz dokumentieren. Hier stellt man fest, dass ein Speicherbedarf von mehreren Terabyte heute auch bei mittelständischen Unternehmen keine Seltenheit mehr darstellt. Ein Kapazitätsbedarf über mehrere Petabyte ist bei Finanzinstituten, TK-Unternehmen und international tätigen Konzernunternehmen an der Tagesordnung. Noch Mitte der 80er Jahre des 20sten Jahrhunderts war es üblich, dass eine physikalische Speichervolumengröße von unter 1 GB ein 15-Zoll Format hatte. Allein der Flächenbedarf wäre riesig, wenn diese Technik sich noch heute im Einsatz befinden würde. Unabhängig von der nicht vorhandenen Anschlusstechnik, es würden Stellflächen in  9

Wikipedia, http://de.wikipedia.org/wiki/Daten#Informatik.

16

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.1. Anforderungen an das Informationsmanagement

der Größenordnung von Turnhallen benötigt, um allein ein Petabyte Kapazität verfügbar zu machen. Die technische Entwicklung in Richtung externer Speichersubsysteme und der Anschluss über Storage Area Networks (SAN), Network Attached Storage (NAS) und Internet Small Computer System Interface (iSCSI) führten dazu, dass Petabyte an Festplattenkapazität in einigen wenigen Speichersubsystemen untergebracht werden können.10 Betrachten wir jedoch die Entwicklung der Informationsspeicherung der vergangenen Dekaden, so stellen wir fest, dass Speicherkonsolidierungsprojekte allein den Zweck verfolgten, auf neue Anschlusstechniken wie SAN und NAS zu migrieren und die technische Entwicklung der Speichersysteme zu implementieren. Speicherkonsolidierungen in Form von „Einsparungen“ von Daten, also Datenreduktion, haben nicht stattgefunden. Diese technologiegetriebene Speicherkonsolidierung führt zu den beiden ersten Herausforderungen an das Informationsmanagement: x Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen Das Informationswachstum sorgt für Innovationsprojekte innerhalb der IT. Die Infrastrukturanpassungen sind technologiefolgend und eher nicht geschäftsprozess-orientiert. Die Budgetierung dieser Anpassungen sind Investi 10

Vgl. Sollbach, Wolfgang: Storage Area Networks/ Network Attached Storage. Hohe Datenverfügbarkeit durch Speichernetzwerke, München, 2001. Vgl. auch: Robbe, Björn: SAN. Storage Area Network, Wiesbaden, 2004.

2.1 Anforderungen an das Informationsmanagement

17

tionen in die IT, ohne direkt den Nutzen für den Geschäftszweck des Unternehmens darstellen zu können. x Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität Auch die Skalierung stellt den CIO der Unternehmen heute vor die Frage, ob diese Herausforderungen von der unternehmenseigenen IT angegangen oder – da deren Lösung nicht unmittelbar dem Geschäftszweck des Unternehmens dient – eventuell besser outgesourced werden sollten. So konzentriere sich die IT „mit beachtlichem Erfolg auf die Technik. Das beweist der Schub bei der prozess- und serviceorientierten Ausgestaltung von Anwendungslandschaften. Doch nutzt es der IT-Abteilung auf Dauer wenig, ein hervorragender Technologiepartner zu sein. Denn Technologie-Know-how ist in Zeiten zunehmender Standardisierung von IT-Landschaften und wachsender Bereitschaft zur Auslagerung der nicht zum Kerngeschäft gehörenden Tätigkeiten kein Garant für eine gesicherte Zukunft.“11 Dieser Tendenz entgegen wirkt die zweite von uns zu betrachtende Entwicklung der IT in der letzten Dekade. Information hat für jedes Unternehmen eine ständig steigende strategische Bedeutung. Daraus folgen die dritte und vierte aktuelle Herausforderung an die IT und den CIO eines Unternehmens.

2.1.1 Zugriff, Verfügbarkeit und Schutz Die aktuelle Speicherinfrastruktur (Disk, Arrays, IP und SAN-Fabrics, NAS und Tapes) sind potenzielle Ziele für Angriffe (Attacks), da insbesondere hier die Lücken zwischen dem Know-how der Administratoren und dem Level der Implementierung von Sicherheitskonzepten derart groß sind, dass Angriffe sehr einfach und erfolgversprechend für potenzielle Angreifer sind. Durch die steigende Nachfrage an Datenmanagementanbieter nach mehr Sicherheit, nach der Integration von immer mehr Speicher- und Verschlüsselungs-, sowie Sicherheitsfunktionen in ihre Systeme führt dies dazu, dass Unternehmen inkompatible Managementsysteme für die jeweiligen Chiffreschlüssel ihrer Lieferanten zu betreiben haben. Notwendig ist ein Business- und Technologie-Framework für genormte, integrierte Verschlüsselungslösungen. Die resultierenden IT-Herausforderungen sind: x Standardisierte APIs für die Decru Lifetime Key Management (LKM) Appliance, x Developer Kits, x Installationsreferenzen und technischer Support. Diese sind die notwendigen Voraussetzungen für die Integration und Interoperabilität der Lösungen verschiedener Hersteller. Zusätzlich ist eine TCO 11

Nilsson, Ragnar: Die Evolution der IT-Abteilung, in: COMPUTERWOCHE 26/2006, München, 2006, S. 26.

18

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.2. Die IT-Infrastruktur für Zugriff, Verfügbarkeit und Schutz unternehmenskritischer Informationen

Betrachtung (Total Cost of Ownership) für Zugriff, Verfügbarkeit und Schutz der unternehmenskritischen Informationen notwendig. Die Herausforderung an den Zugriff besteht darin, bei möglichst optimalen Kosten möglichst zeitnah die für den jeweiligen Geschäftsprozess benötigten Daten zugreifbar zu machen. Hier geht es um die je nach Wertigkeit und Bedeutung unterschiedliche Speichertechnologie und Zugriffssoftware. Die Verfügbarkeit (Availability) gepaart mit der Business Continuity ist die Forderung nach der 24 u 7 Zugreifbarkeit (d. h. 24 Stunden an 7 Tagen) der geschäftskritischen Informationen. Insbesondere internationale zeitzonenübergreifende Geschäfte erfordern rund um die Uhr die in den SLA (Service Level Agreement) vereinbarte Verfügbarkeit der Daten. Man stelle sich eine internationale Handelsbank und deren Abhängigkeit von den aktuellen Marktinformationen vor und berechne die Kosten, die ein Ausfall eines Handelssystems allein für einige Minuten verursacht, so erkennt man die Notwendigkeit von lokal und remote gespiegelten Daten, Business Continuity gewährleistenden Snapshots und Clone-Platten sowie funktionierende Backup- und Recovery-Strategien und -Systeme. Der Schutz der unternehmenskritischen Informationen kann als Schutz vor Verlust definiert werden. Hier kommen ebenfalls die für die Verfügbarkeit und Business Continuity notwendigen Prozesse und Systeme in Betracht. Definiert man Schutz als Schutz vor Ausspähung oder Missbrauch, so geht es bei dieser

2.1 Anforderungen an das Informationsmanagement

19

Herausforderung um organisatorische und technische Verfahren zur Implementierung eines IT-Grundschutzes. Dieser Service ist ebenfalls eine strategische Herausforderung an die IT der Gegenwart.

2.1.2 Reduktion der Risiken der Non-Compliance Non-Compliance bedeutet die Nichterfüllung gesetzlicher Anforderungen an die Haltung, Speicherung und Verwaltung von Informationen. Eine Vielzahl nationaler und internationaler Regelwerke definieren die Anforderungen an ITSysteme, deren Einhaltung in Summe den Grad der Compliance der Unternehmens-IT bestimmt. Dieses Thema beleuchten die Autoren in einem eigenen Abschnitt. Der Herausforderung Compliance wird in Business Intelligence Systemen (BIS) Rechnung getragen, die über die Erfüllung gesetzlicher Auflagen hinaus die Wettbewerbsfähigkeit von Unternehmen durch höhere Effizienz der Geschäftsprozesse steigern sollen. Dennoch: „Wegen fehlerhafter oder fehlender Unternehmenskennzahlen ins Gefängnis? – So weit ist es noch nicht. Aber nach Enron- und Worldcom-Pleite drohen zumindest amerikanische Richter mit drakonischen Strafen, falls CEOs an US-Börsen falsche Bilanzen abliefern – willentlich oder aus purer Ahnungslosigkeit. Aber auch in Deutschland fordert der Gesetzgeber mehr Budgetklarheit. Gesetzliche Auflagen wie das KonTraG oder die Kreditvergaberichtlinien nach Basel II sollen schon heute für mehr Klarheit über die Unternehmenszahlen sorgen; eine EU-Richtlinie, die nach Ansicht von Experten Sarbanes-Oxley ähneln könnte, ist in Vorbereitung.“12 Die Assekuranzen werden auf Basis von Solvency II ihre Produkte und ihre Preisgestaltung stärker an die tatsächlichen Risiken anpassen, so dass auch die Kunden direkt betroffen sind. Die Bedeutung dieser vierten Herausforderung an die IT mag auch daran ermessen werden, dass analog zur IT-Infrastructure-Library (ITIL) als standardisiertes „Best Practices“ Prozess-Set zur Gestaltung der IT-Services mit COBIT (Control Objectives for Information and related Technology) ein Quasi-Standardset zur Einhaltung der Compliance-Anforderungen zumindest aus Sarbanes-Oxley geschaffen wurde, welches auch innerhalb europäischer Unternehmen zur Kennzahlenermittlung und deren Präsentation immer mehr an Bedeutung gewinnt. Informationsmanagement, will mit Prozess-Know-how, Fach- und Branchenkompetenz die Geschäftsprozesse des Unternehmens unterstützen und muss deshalb für sämtliche Herausforderungen Strategien zur Erfüllung der Anforderungen entwickeln und erfolgreich einsetzen (s. Abb. 2.3). Die Steuerbehörden der Bundesrepublik Deutschland haben mit der Umsatzsteuer-Nachschau in §27b Umsatzsteuergesetz (USTG) seit 01.01.2002 auch das Recht, für Zwecke der Umsatzsteuer ohne vorherige Ankündigung während der Geschäfts- oder Arbeitszeiten, die Grundstücke und Räume eines Steuerpflichtigen zu betreten, der eine gewerbliche oder berufliche Tätigkeit selbständig  12

Business Intelligence, Verlegerbeilage, COMPUTERWOCHE 26/2006, München, 2006, S. 27.

20

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.3. IT-Strategien für das Informationsmanagement

ausübt.13 Damit müssen die Compliance-Anforderungen nicht nur zu einem definierten Stichtag, sondern jederzeit erfüllt werden. Die dritte zu untersuchende Entwicklung innerhalb der Informationstechnologie führt uns zum Information Lifecycle als speziellen Produktlebenszyklus der Information. Information verändert im Zeitverlauf ihren Wert für das Unternehmen.

2.1.3 Fähigkeit, Informationsmanagement anhand des Informationswertes zu priorisieren Die Herausforderung besteht darin, den spezifischen Informationslebenszyklus zu erarbeiten und daraus den Strategien-Mix des Informationsmanagements abzuleiten, um dieser Herausforderung zu begegnen. Die Strategien des Informationsmanagements zur Erfüllung der Anforderungen x Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen und x Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität sind technologiegetrieben.  13

§27b Umsatzsteuergesetz (USTG).

2.1 Anforderungen an das Informationsmanagement

21

Abb. 2.4. Entwicklungsschritte der IT14

Die optimale Auslastung der IT-Infrastruktur sowie die Vereinfachung und Automatisierung der Administration der Informationsinfrastruktur sind Strategien, deren Erfolg die IT als Technologiepartner des Business im Unternehmen belässt (s. Abb. 2.4). Diese beiden Anforderungen sind jedoch auch die kritischen Punkte zur Legitimation der internen IT. Sind die hier gewählten Strategien nicht erfolgreich, ist die interne IT stark durch Outsourcing gefährdet. Die Steigerung der Kosteneffizienz für Zugriff, Business Continuity und Schutz der unternehmensrelevanten Informationen als Strategie erfordern die Erfüllung der Anforderung: x TCO-Betrachtung für Zugriff, Verfügbarkeit und Schutz der unternehmenskritischen Informationen sowie die Sicherstellung der Compliance durch policy- und prozessbasierende Business-Intelligence-Verfahren und x Reduktion der Risiken der Non-Compliance, die die IT zum Prozesspartner des Business und eventuell sogar bereits zum Erfolgspartner machen. Die Strategie zur Lieferung eines an dem Informationswert orientierten ITServices als Lösungsstrategie für Anforderungen besteht aus der Fähigkeit, das Informationsmanagement auf Grundlage des Wertes der Information zu priorisieren. Durch die strategiekonforme Ausrichtung kann die IT die aus heutiger Sicht höchste Evolutionsstufe erreichen.  14

Nilsson, Ragnar, a.a.O., S. 26.

22

2 Information Lifecycle und Information Lifecycle Management

Diese Strategie macht die Unternehmensziele zu IT-Zielen. Sie ist die umfangreichste Strategie und durchläuft sämtliche Evolutionsstufen der Entwicklung der IT. Daher enthält sie quasi als Container auch sämtliche Strategien der Vorläufer-Evolutionsschritte. Aus diesem Grunde müssen wir uns in diesem Buch auch mit sämtlichen Strategien und deren Umsetzung auseinandersetzen, auch wenn dem äußeren Scheine nach nur die letzte Herausforderung und die Strategien zu deren Erfüllung dem Thema des Buches entsprechen.

2.2 Der Informationslebenszyklus Das Informations-Zeit-Diagramm in der folgenden Abbildung zeigt den typischen Lebenszyklus von Informationen. In der Erstellungsphase werden Informationen erzeugt. Als Beispiel mag hier der Prozess zur Erstellung eines neuen Auftrages dienen. Zur Erstellung des Auftrages werden die Kundendaten, die Auftragsdaten erzeugt sowie Zahlungskonditionen und -wege erfasst. Es werden Kundenstammdaten, Auftragsstammdaten und Rechnungsstammdaten erzeugt, sowie Abgleiche mit der Schufa und bestehenden Daten durchgeführt. Die Zwischenergebnisse der Prozesse werden gespeichert. Letztendlich wird der gesamte neue Auftrag als Information gespeichert. Die Verdichtungsphase ist die Phase, in der die Information verarbeitet wird. In unserem Beispiel ist dies die Phase der Auftragsbearbeitung. Hier wird die

Abb. 2.5. Der Lebenszyklus der Information

2.2 Der Informationslebenszyklus

23

Lieferung zusammengestellt, an den Kunden versandt sowie die Rechnungsstellung veranlasst. Gespeichert werden unterschiedliche Statusdaten der auftragsbezogenen Informationen. Die Nutzungsphase der Information ist in unserem Beispiel der Zeitraum bis zum vollständigen Abschluss des Auftrages und dem Eingang der Zahlung. Der Nutzungszeitraum von Teilinformationen wie beispielsweise der Kundenstammdaten ist natürlich bedeutend länger. In diesem Beispiel wäre der Nutzungszeitraum dieser Daten bis zu dem Zeitpunkt ausgedehnt, an dem die Geschäftsbeziehungen zu diesem Kunden enden. Die Bewahrungsphase beschreibt den Zeitraum, in dem eine Information zwar keiner Änderung mehr unterliegt, dennoch permanent zugreifbar gehalten wird, um Statusänderungen schnell begegnen zu können. Im Beispiel der Auftragsbearbeitung ist der Bewahrungszeitraum der Zeitabschnitt zwischen Auftragsabschluss und Ablauf von Garantie- und Gewährleistungsfristen. Die Archivierungsphase ist die Phase, in der Informationen aus gesetzlichen oder betrieblichen Anforderungen aufbewahrt, jedoch nicht mehr direkt zugreifbar gehalten werden müssen. Für das Beispiel unserer Auftragsbearbeitung ist der Archivierungszeitraum beispielsweise die 10-jährige Aufbewahrungspflicht und Wiederherstellbarkeitsanforderung sämtlicher geschäftsvorfallbezogener kaufmännisch relevanter Dokumente. Dabei kann der Informationslebenszyklus – wie in unserem Beispiel – geschäftsvorfallbezogen dargestellt werden (Verfolgung eines Auftrages von der

Abb. 2.6. Information Lifecycle und IT-Systeme

24

2 Information Lifecycle und Information Lifecycle Management

Erstellung bis zum letztendlichen Löschen der Informationen), er kann jedoch auch IT-System-bezogen visualisiert werden. Der Wert der Information ist in der Erstellungs-, Verdichtungs- und Nutzungsphase hoch. Hier wird aktiv mit der Information gearbeitet. Die Information wird stetig genutzt, auf sie wird beständig zugegriffen. Die Information selbst oder ihr Status unterliegt einer häufigen Änderung. Informationen in diesen Phasen sind in der Informationsgesellschaft „Anlagegüter“, ihre Aktualität macht ihre Qualität und ihren Wert aus. In der Bewahrungsphase sinkt zunächst der Wert der Information. Die Information ist auf einem letzten Zustand eingefroren (abgeschlossener Auftrag). Der Wert der Information kann nochmals stark ansteigen, wenn eintretende Gewährleistungspflichten oder Garantien Aktualisierungen des letzten Status erfordern. In der Archivierungsphase verliert die Information an Wert für das Unternehmen. Sie wird für geschäftliche Zwecke des Unternehmens nicht mehr genutzt, sondern lediglich aus Aufbewahrungspflichten wiederherstellbar gespeichert. Ist die Aufbewahrungsfrist abgelaufen, wird die Information gelöscht. Der Wert der Information ist natürlich abhängig von ihrer Qualität. Die Qualität der Information wird dadurch charakterisiert, dass sie vollständig genutzt werden kann und kein Teil der die Information repräsentierenden Daten unnötig ist. Die Qualität der Information lebt mit der Qualität der Prüfung zum Erstellungszeitpunkt, die sicherstellen soll, dass die Information eine hohe Visibilität besitzt. Besonders bei der Erfassung unstrukturierter Daten (E-Mails,

Abb. 2.7. Informationswert im Lebenszyklus

2.2 Der Informationslebenszyklus

25

Abb. 2.8. Informationsqualität im Lebenszyklus

Textdokumente etc.) ist hier häufig ein Mangel an Visibilität festzustellen. Es besteht eine signifikante Gefahr, Ressourcen für Informationen geringen Werts zu verschwenden. Werden die so gewonnenen Informationen hoher Qualität in ihrem Lebenszyklus verwendet, muss der notwendige Zugriff auf die jeweils statuskonforme Kopie gewährleistet werden. Hier muss darauf geachtet werden, dass keine unnötigen Kopien ein und derselben Information gehalten werden, nur weil der Zugriff nicht befriedigend gelöst wurde. Die Zirkulation einer Vielfalt von Kopien verschwendet nicht nur Ressourcen, sondern gefährdet auch die Konsistenz der Geschäftsprozesse des Unternehmens. Entscheidungen auf Grundlage einer „falschen“ Kopie, die die aktuellen Statusänderungen der Information nicht beinhaltet, können fatale Auswirkungen haben. Am Ende des Lebenszyklus der Information muss sichergestellt werden, dass die Archivierung der Compliance-Anforderung genügt und dass nach Ablauf sämtlicher Aufbewahrungsfristen die nun nicht mehr benötigte Information prozessbasiert automatisch gelöscht wird. Ist dies nicht der Fall, besteht die Gefahr, dass nicht mehr benötigte Informationen über lange Zeiträume Ressourcen in Anspruch nehmen.

2.2.1 Kosten im Informationslebenszyklus Betrachtet man die Kosten der Information über ihren Lebenszyklus, so lassen wir zunächst die eventuell nicht unerheblichen Kosten der Informationsgewinnung außer Acht.

26

2 Information Lifecycle und Information Lifecycle Management

Die Kosten der Information setzen sich zusammen aus: x Kosten der Softwareinfrastruktur der Informationshaltung; x Kosten der Hardwareinfrastruktur der Informationshaltung und x Kosten der Prozessinfrastruktur der Informationshaltung. Die Kosten der Softwareinfrastruktur der Informationshaltung setzen sich zusammen aus den Beschaffungs- und Lizenzkosten für eingesetzte Softwaresysteme, Kosten für Beschaffung und Lizenzen eingesetzter und benötigter Schnittstellensysteme sowie eventuell zusätzlichem Wartungsaufwand für die eingesetzten Softwaresysteme. Die Kosten der Hardwareinfrastruktur der Informationshaltung addieren sich über die Beschaffungs- und Wartungskosten der benötigten Primärtechnik (Server, Clients, Speichersysteme, SAN, Netzwerkinfrastruktur etc.) sowie der eingesetzten Sekundär- und Tertiärtechniken (Strom, Wasser, Kühlung, Abluft und Kosten des Rechenzentrumsbetriebes). Die Kosten der Prozessinfrastruktur der Informationshaltung bestehen aus den Personalkosten des Rechenzentrumsbetriebes, Beratungskosten, Abstimmung zwischen Fachabteilung und IT etc. Zum Zeitpunkt der Erstellung der Information erzeugt diese bereits einen hohen Kostensatz, da sie zu Beginn ihres Lebenszyklus für den direkten Zugriff auf den Produktionssystemen des Unternehmens gelagert und verarbeitet wird. Dieser direkte Zugriff bedingt, dass die Information hier auf teurer Primärtechnik residiert. Erfasst werden Informationen aus CRM-Systemen, anschließend werden sie in ERP-Systeme als zentrale Anwendungssysteme des Unternehmens eingepflegt und mit bereits existierenden Informationen im Informationszusammenhang (Kunde, Kundenort, Vertriebsweg, Zahlungsdaten usw.) abgeglichen. Die Kosten der Prozessinfrastruktur sind in dieser Phase ebenfalls intensiv. Man betrachte die involvierte Softwareinfrastruktur. Diese Systeme stellen in aller Regel die Produktivsysteme der Unternehmens-IT dar. Auf Grundlage der in diesen Systemen gespeicherten Daten und Prozesse unterstützt die IT die Geschäftsprozesse des Unternehmens. Diesen Systemen gilt im IT-Betrieb die höchste Aufmerksamkeit. Ein Service Level Agreement (SLA) für diese Systeme ist hinsichtlich Verfügbarkeit, Business Continuity, Performance, Betriebsnebenzeiten und Betriebshauptzeiten das umfangreichste Dokument, das Unternehmen mit ihrem Technologiepartner abgeschließen. Die eingesetzte Primärtechnik ist für hohe Verfügbarkeit ausgelegt. Die verwendeten Serversysteme sind häufig Clustersysteme, die über ein Storage Area Network auf externe Speichermedien zugreifen. Der Zugriff ist auch noch redundant über multiple Zugriffspfade über mehrere Switche innerhalb der SANFabric abgesichert. Die physikalischen Speichermedien (HDAs) sind innerhalb der Speichersysteme gespiegelt oder mit einem hohen RAID-Schutz abgesichert. Optimale Business Continuity ist gewährleistet durch den Einsatz von Cloning- und SnapshotTechnologien. Durch Datensicherungsstrategien über mehrere Generationen auf Disk- oder Magnetband-Libraries, eventuell sogar eine Zwischensicherung auf

2.2 Der Informationslebenszyklus

27

Abb. 2.9. Die Kosten der Information im Lebenszyklus

SATA-Platten im Speichersystem, wird gewährleistet, dass bei logischen und physikalischen Fehlern die Ausfallzeiten minimiert und ein Datenverlust ausgeschlossen wird. Diese hochausfallsicheren Produktivsysteme werden häufig noch aus Desaster-Recovery-Gründen auf identischen Remote-Systemen in Notfall-, K-Fall- oder Desaster-Rechenzentren gespiegelt. Dies ermöglicht den Zugriff auf die Daten mit einer minimalen Verzögerung auch im Falle elementarer Katastrophen, bei denen eine komplette RZ-Infrastruktur verloren geht. Die häufig genannten Einsatzszenarien für solche Remote-Systeme wie Flugzeugabsturz oder Terroranschlag sind zwar jeweils bereits eingetreten, entbehren jedoch aufgrund ihrer extrem geringen Eintrittswahrscheinlichkeit des notwendigen Furchtpotenzials. Weniger häufig genannte Szenarien sind jedoch um vieles wahrscheinlicher. Man denke an die Gefährdung eines Rechenzentrums durch Unfälle mit ätzenden Chemikalien an viel befahrenen Eisenbahnstrecken oder Straßen, die Gefährdung durch lokale Naturkatastrophen (Wassereinbruch bei starken Gewittern) oder auch die weltweit häufiger werdenden Wetterereignisse. Hurrikan Caterina oder die Elbeflut der Jahre 2002 und 2006 haben in weitaus höherem Umfang das Umschalten zu Notfallrechenzentren erfordert als die Terror-Katastrophe des 11. September in New York. Gehen wir davon aus, dass nahezu 100 Prozent der Daten in der Phase der Erstellung in einer solchen Umgebung gespeichert und betrieben werden, so sind die hohen Kosten der Software-, der Hardware- und der Prozessinfrastruktur in dieser Lebenszyklusphase einleuchtend. Während der Verdichtungsphase und der Nutzungsphase wird die Information weiter auf der teuren Primärtechnik gehalten. Damit steigen die Kosten der Soft-

28

2 Information Lifecycle und Information Lifecycle Management

wareinfrastruktur als auch die Kosten der Prozessinfrastruktur. Während in der Erstellungsphase Rohdaten erzeugt wurden (Kundenstammsatz, Auftragsdaten, Daten zur Rechnungsstellung), werden diese in der Verdichtungsphase für die Geschäftsprozesse des Unternehmens aufbereitet. Als Beispiel mag ein TK-Unternehmen dienen. In der Erstellungsphase werden bei diesem Unternehmen Rohdaten generiert. Es werden rufnummernbezogene Informationen gespeichert, wie Anrufziel, -dauer, Mobilfunkzelle, aus der der Anruf stattgefunden hat, usw.15 Diese Verkehrsdaten dürfen nach TKG 2004 § 96 Absatz (2) „über das Ende der Verbindung hinaus nur verwendet werden, soweit sie zum Aufbau weiterer Verbindungen oder für die in den §§ 97 [Entgeltermittlung und Entgeltabrechnung, die Autoren], 99 [Einzelverbindungsnachweis, die Autoren], 100 [Störungen von Telekommunikationsanlagen und Missbrauch von Telekommunikationsdiensten, die Autoren] und 101 [Mitteilen ankommender Verbindungen, die Autoren] genannten Zwecke erforderlich sind. Im Übrigen sind Verkehrsdaten vom Diensteanbieter nach Beendigung der Verbindung unverzüglich zu löschen.“16 Die Verdichtungsphase ist hier die erste Phase, in der diese Informationen in Servicemanagementsystemen verwaltet und verarbeitet werden. Wesentliche Funktionen dieser Servicemanagementsysteme sind: x „Customer Care (Pflege der Kundendatenbasis, Entgegennahme von Kundenaufträgen, Beantwortung von Fragen) x Billing (Gebührenermittlung, Rechnungserstellung, Zahlungskontrolle) […]. Die Servicemanagementsysteme sind der kritischste Teil der TMN- [Telecommunication Management Networking, die Autoren] Umgebung jedes Betreibers, da die Arbeitsfähigkeit von ihrer ständigen Funktionsfähigkeit abhängt. Entsprechend hoch sind auch die Kosten, die ein Betreiber in diese Systeme investieren muss. Ein Billingsystem für einen großen (nationalen) Betreiber kann inklusive Anpassung an neue Anforderungen und Wartung über fünfzig (oder einige hundert) Millionen Euro kosten.“17  15

16 17

„TKG 2004 § 96 Verkehrsdaten Der Diensteanbieter darf folgende Verkehrsdaten erheben und verwenden, soweit dies für die in diesem Abschnitt genannten Zwecke erforderlich ist: – die Nummer oder Kennung der beteiligten Anschlüsse oder der Endeinrichtung, personenbezogene Berechtigungskennungen, bei Verwendung von Kundenkarten auch die Kartennummer, bei mobilen Anschlüssen auch die Standortdaten, – den Beginn und das Ende der jeweiligen Verbindung nach Datum und Uhrzeit und, soweit die Entgelte davon abhängen, die übermittelten Datenmengen, – den vom Nutzer in Anspruch genommenen Telekommunikationsdienst, – die Endpunkte von fest geschalteten Verbindungen, ihren Beginn und ihr Ende nach Datum und Uhrzeit und, soweit die Entgelte davon abhängen, die übermittelten Datenmengen, – sonstige zum Aufbau und zur Aufrechterhaltung der Telekommunikation sowie zur Entgeltabrechnung notwendige Verkehrsdaten.“ Aus: Telekommunikationsgesetz Geltung ab 26.06.2004. Zuletzt geändert durch Art. 3 Abs. 2 G v. 7. 7.2005 I 1970, Bundesministerium der Justiz, 2004, 2005. A.a.O. Bergmann, Friedhelm, Gerhardt, Hans-Joachim, Frohberg, Wolfgang: Taschenbuch der Telekommunikation, 2. Aufl., Leipzig, 2003, S. 553.

2.2 Der Informationslebenszyklus

29

Dieses Beispiel mag die während der Verdichtungs- und Nutzungsphase des Informationslebenszyklus noch ansteigenden Kosten der Softwareinfrastruktur und der Prozessinfrastruktur verdeutlichen. Die Bewahrungsphase ist dadurch gekennzeichnet, dass die Kosten für Hardware- und Softwareinfrastruktur abnehmen, da die Information von teuren auf günstigere Medien verlagert wird. Ferner sollte hier eine Reduktion der Daten vorgenommen werden. Nur noch die Daten, die aufbewahrt werden müssen, um die Geschäftsvorfälle des Unternehmens zu unterstützen oder gesetzlichen Auflagen gerecht zu werden, sollten gehalten werden. Ebenfalls sinken die Kosten der Prozessinfrastruktur. Die Information unterliegt seltenen Änderungen; Datensicherungsverfahren und -häufigkeiten werden dieser Situation angepasst. Wenden wir uns wieder unserem Beispiel des Telekommunikationsunternehmens zu, so ist dieses gemäß dem Abschnitt 3 (Öffentliche Sicherheit) des Telekommunikationsgesetzes für einen eingeschränkten Zeitraum (z. Zt. 6 Kalendermonate) zur Speicherung und Übermittlung von Daten auch nach Rechnungsstellung verpflichtet. So regelt TKG 2004 § 111 (Daten für Auskunftsersuchen der Sicherheitsbehörden) (TKG 1996 § 90), welche Informationen durch Sicherheitsbehörden in dem in § 112 geregelten automatisierten Auskunftsverfahren und dem in § 113 fixierten manuellen Auskunftsverfahren abgefragt werden können. Basis für das Auskunftsersuchen der Sicherheitsbehörden ist:18 (1) Wer geschäftsmäßig Telekommunikationsdienste erbringt oder daran mitwirkt und dabei Rufnummern vergibt oder Telekommunikationsanschlüsse für von anderen vergebene Rufnummern bereitstellt, hat für die Auskunftsverfahren nach den §§ 112 und 113 die Rufnummern, den Namen und die Anschrift des Rufnummerninhabers, das Datum des Vertragsbeginns, bei natürlichen Personen deren Geburtsdatum, sowie bei Festnetzanschlüssen auch die Anschrift des Anschlusses vor der Freischaltung zu erheben und unverzüglich zu speichern, auch soweit diese Daten für betriebliche Zwecke nicht erforderlich sind; das Datum des Vertragsendes ist bei Bekanntwerden ebenfalls zu speichern. Satz 1 gilt auch, soweit die Daten nicht in Teilnehmerverzeichnisse (§ 104) eingetragen werden. Wird dem Verpflichteten nach Satz 1 eine Änderung bekannt, hat er die Daten unverzüglich zu berichtigen; in diesem Zusammenhang hat er bisher noch nicht erfasste Daten nach Satz 1 nachträglich zu erheben und zu speichern, sofern ihm eine Erhebung der Daten ohne besonderen Aufwand möglich ist. Nach Ende des Vertragsverhältnisses sind die Daten mit Ablauf des auf die Beendigung folgenden Kalenderjahres zu löschen. Eine Entschädigung für die Datenerhebung und -speicherung wird nicht gewährt. Für das Auskunftsverfahren nach § 113 ist die Form der Datenspeicherung freigestellt. Hier ist die Verpflichtung des TK-Betreibers geregelt, diese Daten vorzuhalten. Da der Betreiber diese Daten jedoch für keine Business-ManagementAnwendungen benötigt, wird er im Interesse der Kostenminimierung die Kosten  18

A.a.O.

30

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.10. Phasen des Informationslebenszyklus

für die Software-, Hardware- und Prozessinfrastruktur für die Bereitstellung der Informationen minimieren. Dennoch wird er diese Daten vor Veränderung und Verlust schützen, da TKG 2004 § 115 (Kontrolle und Durchsetzung von Verpflichtungen) der Regulierungsbehörde die Möglichkeit gibt, rigorose Strafen von Zwangsgeldern ab 20.000,- Euro bis hin zum Lizenzentzug auszusprechen. Daher nehmen in der Bewahrungsphase die Kosten der Software-, Hardwareund Prozessinfrastruktur lediglich moderat ab. Die Archivierungsphase ist charakterisiert durch noch günstigere Medien sowie keine sonderlich hohen zusätzlichen Kosten für Software- und Prozessinfrastruktur. In dieser Phase werden geschäftsbezogene Dokumente für einen teilweise großen Zeitraum dokumentenecht und schreibgeschützt aufbewahrt (vgl. juristische Grundlagen für ILM in Kap. 3). Die hier anfallenden Kosten entstehen bei der Beschaffung, dem Betrieb und der Wartung der Archivierungshardund -Software. Nach Abschluss der Archivierungsphase wird die gespeicherte Information gelöscht und verursacht keine weiteren Kosten.

2.3 Der Informationslebenszyklus-Strategien-Mix Zentrale Wettbewerbsvorteile, die auch als kritische Erfolgsfaktoren bezeichnet werden können, ändern sich im Zeitablauf. So beruhte der Wettbewerb in den

2.3 Der Informationslebenszyklus-Strategien-Mix

31

70er Jahren in erster Linie nur auf Kostenvorteilen. In den 80er Jahren trat demgegenüber der reine Kostenvorteil in den Hintergrund und Qualität gewann zunehmend an Bedeutung. In den 90er Jahren schließlich wurde angesichts der Dynamik auf den Märkten und der ständigen Produktinnovationen die „Time to Market“ bedeutender. Heute ist Information und Wissen der kritische Erfolgsfaktor. Die Flexibilität und die Fähigkeit, die Umweltveränderungen zu antizipieren oder gar im Sinne der eigenen Interessen selbst zu bestimmen, basiert im Wesentlichen auf Information. Dies gilt sowohl für die industrielle Produktion mit den Möglichkeiten zum Global Sourcing als auch insbesondere für Dienstleistungen. Das Qualitätsmanagement von Produktion und Dienstleistungen hat sowohl eine strategische als auch eine operative Komponente und weist somit eine Verbindung zu den strategischen und operativen Managementaufgaben auf. Die strategische Verbindung ergibt sich aus der Bedeutung der Qualität als möglicher Wettbewerbsvorteil. Qualitätsmanagement wirkt dabei sowohl nach innen als auch nach außen. Die Aufgaben des Qualitätsmanagements liegen sowohl im Bereich des Leistungserstellungsprozesses als auch der Sicherung des Leistungspotenzials. Qualität weist auf der operativen Ebene eine enge Verbindung zur Effektivität auf und damit zum Kostenmanagement. Ebenso wie das Qualitätsmanagement weist auch das Kostenmanagement von Dienstleistungen eine sehr enge Korrelation zur Stärke der Wettbewerbsfähigkeit auf. Allerdings bezieht sich das Kostenmanagement in stärkerem Maße auf

Abb. 2.11. Der IT-Strategien-Mix im Informationslebenszyklus

32

2 Information Lifecycle und Information Lifecycle Management

Tabelle 2.1. Beschreibende Attribute für Software-, Hardware- und Prozessinfrastruktur Attribut

Beschreibung

Betriebszeit

Betriebszeit ist die Hauptbetriebszeit, d. h. hier ist die Mehrzahl der Benutzer mit der Anwendung beschäftigt. Bei Online-Anwendungen handelt es sich um die Hauptgeschäftszeiten, Batch-Anwendungen haben in der Regel ihre Hauptbetriebszeit nach Ende der Hauptgeschäftszeiten.

Betriebsnebenzeiten

Betriebszeiten einer Anwendung nach/vor der Hauptbetriebszeit. Dies sind Zeiten, zu denen die Anwendung zu Vor- und Nachverarbeitung verfügbar sein muss.

Hardwareverfügbarkeit

Maximaler Zeitraum für Wiederherstellung der Hardwareverfügbarkeit einer Anwendung. Je redundanter die Hardwareausstattung einer Anwendung ausgelegt ist, umso geringer ist die Dauer der physischen Wiederherstellung und umso größer ist die Hardwareverfügbarkeit.

Logische Maximaler Zeitraum für die logische Wiederherstellung der AnwenWiederdungsdaten. Die logische Wiederherstellung geht somit über die physische herstellung Wiederherstellung insofern weit hinaus, als hier der Anwendung nach einem Störfall sämtliche Daten bis zu denen der letzten konsistenten Transaktion vor dem Störfall wieder zugänglich gemacht werden müssen. Je kürzer die Anforderungen an die logische Wiederherstellung sind, umso aufwendiger muss Software-, Hardware- und Prozessinfrastruktur gestaltet sein. Maximaler geplanter, d. h. maximal zulässiger Datenverlust

Der maximal zulässige Datenverlust steht in enger Relation zum Attribut logische Wiederherstellung. Auch Datenverlust ist planbar. Eine Wiederherstellung bis zur letzten Transaktion vor der Störung erfordert ein transaktionssicheres Datenbankmanagementsystem, idealerweise lokale und remote physikalische Spiegelung der Daten sowie ein Backup-RestoreVerfahren, das physikalisch und logisch eine Wiederherstellung bis zur letzten konsistenten Transaktion vor der Störung und ein zeitpunktgenaues Wiederherstellen der unstrukturierten Daten der Anwendung ermöglicht. Je geringer der geplante Datenverlust ist, desto aufwendiger muss die Software-, Hardware- und Prozessinfrastruktur gestaltet sein.

ServiceDesk

Wird die Steuerung der Bearbeitung von Störungen über einen ServiceDesk benötigt? Zu welchen Zeiten muss der Service-Desk verfügbar sein?

Reaktionszeiten

Wie groß darf der Zeitraum nach Eintreten einer Störung sein, bis mit der Bearbeitung der Störung begonnen wird? Wann muss nach Auftreten der Störung die Störung behoben sein? Sehr schnelle Reaktionszeiten sind i.d.R. nur durch die Einschaltung eines Service-Desk zu den Betriebszeiten und die Einführung von Bereitschaften in den Betriebsnebenzeiten zu realisieren.

Bereitschaft

Das Attribut Bereitschaft beschreibt, ob zur Aufrechterhaltung der Reaktionszeiten eine Bereitschaft in den Betriebsnebenzeiten eingeführt werden muss. Für die Betriebszeiten ist ein Service-Desk zur Kanalisation der Störungsmeldungen für schnelle Reaktionszeiten unabdingbar.

2.3 Der Informationslebenszyklus-Strategien-Mix

33

die Realisierung des Anbietervorteils, da hier die geringeren Kosten aus Sicht des Kunden einen Vorteil darstellen. Kostenmanagement ist daher in operativer Hinsicht mit der Effizienz verbunden und wird durch das Wirtschaftlichkeitsprinzip realisiert. Für Produkte und insbesondere für Dienstleistungen sind Informationen von mehrfacher Bedeutung (wie bereits beschrieben). Mit ihrer Hilfe kann das Unternehmen seinen eigenen Leistungserstellungsprozess steuern. So können etwa die Informationen aus Kundenkontakten und Kundenbeschwerden für die Verbesserung der Produkte und Dienstleistungen genutzt werden. Dies gilt auch für die Beobachtung des Kundenverhaltens. Die Weiterleitung, Speicherung und vor allem die Nutzung dieser kundenbezogenen Informationen sind von besonderer Bedeutung für den Aufbau von Wettbewerbsvorteilen. Hier steht auch der Aufbau von Kernkompetenzen zur Disposition. Nachdem neben dem Merkmal Wert auch die wichtigen Größen Qualität und Kosten der Information in ihrem Lebenszyklus untersucht wurden, muss nun der IT-Strategien-Mix pro Lebenszyklusphase erarbeitet werden, um einen jeweils geeigneten Strategien-Mix gemäß der aktuellen Wettbewerbssituation zur Verfügung zu stellen. Bei der Betrachtung des Strategien-Mix fällt auf, dass unabhängig von der Lebenszyklusphase die Strategie für die Software-, Hardware- und Prozessinfrastruktur sowie die Anpassung an den Wert der Information stets die gleiche zu sein scheint. Dieser Eindruck verliert sich jedoch, wenn man phasenbezogen die einzelnen Maßnahmen zur Implementierung der Strategie vergleicht. Außerdem unterscheiden sich die jeweiligen Anforderungen in den einzelnen Phasen hinsichtlich der Ausprägung bestimmter beschreibender Attribute. Diese beschreibenden Attribute sollen hier nur auf die Produktivsysteme angewandt werden. Dennoch können diese Kriterien ebenfalls an die Systeme in Entwicklungs-, Test- und PreLife-Umgebungen angesetzt werden. Der Strategien-Mix in der Erstellungsphase wird implementiert, indem bei der Softwareinfrastruktur die neuen Daten möglichst schnell den existierenden Geschäftsanwendungen verfügbar gemacht werden. Hier geht es darum, möglichst nahe „am Kunden“ die Datenerstellung zu ermöglichen. Ein Telefoniekunde möchte im Shop seiner Telefongesellschaft einen neuen Vertrag abschließen. Hier muss sichergestellt sein, dass der Kundenbetreuer vor Ort die für den Vertrag relevanten Informationen/Daten erfassen kann. Das Servicemanagement der Telefongesellschaft ist sicherlich zentralisiert und bestimmt werden diese Daten auch über die zentralen Geschäftsanwendungen erfasst und gespeichert, auf Konsistenz geprüft, mit existierenden Verträgen des Kunden abgeglichen usw. Es wäre jedoch für den positiven Vertragsabschluss wahrscheinlich tödlich, würde die Aufnahme der Daten durch eine Netzstörung oder ein zentrales RZ-Betriebsproblem der Telefongesellschaft nicht stattfinden können. Hier bedeutet die Strategie „Gewährleistung schneller Verfügbarkeit für sämtliche Geschäftsprozesse“, dass die Softwareinfrastruktur unabhängig von zentralen Architekturen vor Ort sämtliche Aktivitäten zum Vertragsabschluss unterstützen muss. Sollten zeitnahe Abgleiche mit der zentralen IT nicht möglich sein, muss die Softwarearchitektur einen asynchronen Austausch bieten. In

34

2 Information Lifecycle und Information Lifecycle Management

der zentralen IT wird seitens der Softwareinfrastruktur ein geschäftskritisches OLTP-System, performante Datenbankmanagementsysteme, ein 24 u 7 verfügbares CRM- und ERP-System vorhanden sein. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert hier ein Release-Management, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Außerdem muss gewährleistet sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. An jedem Arbeitsplatz muss die Softwareinfrastruktur vorhanden sein, die zur Erfassung einer Information und deren Transport zur zentralisierten IT benötigt wird. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Erstellungsphase, dass am Ort der Informationserstellung jeder an der Erstellung beteiligte Unternehmensmitarbeiter Zugriff auf die benötigte Hardware hat. Dies bedeutet nicht, dass jeder Mitarbeiter einen festen ihm allein zugeordneten Arbeitsplatzrechner für die von ihm benötigten Anwendungen hat. Falls der jeweilige Arbeitsplatzrechner mit diesen Anwendungen ausgelastet ist, nun gut. Falls nicht, dies dürfte in der Mehrzahl der Fälle so sein, wird Auslastungsoptimierung eventuell durch einen Terminalservice erzielt, der die Funktionalität auf einen Server konzentriert und die Präsentation je Mitarbeiter über Terminals gewährleistet. Dies bedeutet jedoch auch, dass die RZ-Infrastruktur die hohen Anforderungen der Erstellungsphase erfüllen muss. Hier wird hochverfügbare Server- (Cluster) und Storage-Infrastruktur benötigt.

Tabelle 2.2. Attributausprägungen der Erstellungsphase Attribut

Beschreibung

Betriebszeit

Montag bis Freitag: 07:00 Uhr bis 22:00 Uhr Samstag: 07:00 Uhr bis 14:00 Uhr

Betriebsnebenzeiten

Montag bis Freitag: 22:00 Uhr bis 07:00 Uhr Samstag: 14:00 Uhr bis 24:00 Uhr Sonntag: 00:00 Uhr bis 24:00 Uhr

Hardwareverfügbarkeit

Maximal 14 Stunden

Logische Wiederherstellung

Maximal 4 Stunden

Maximaler geplanter, Erfassungssystem: 0 Minuten d. h. maximal zuläs- Synchronisationssysteme: 30 Minuten (jedoch manuell aus Dasiger Datenverlust ten der Erfassungssysteme wiederherstellbar, sonst 0 Minuten) Service-Desk

Ja, in Betriebszeiten

Reaktionszeiten

Betriebszeit: Maximal 15 Minuten Betriebsnebenzeit: Maximal 30 Minuten

Bereitschaft

Ja, in Betriebsnebenzeiten

2.3 Der Informationslebenszyklus-Strategien-Mix

35

Die Wahrscheinlichkeit, dass auf Daten der Erfassungsphase sehr schnell wieder zugegriffen wird, ist sehr hoch. Dies erfordert in der Erfassungsphase ITPrimärtechnik der Enterprise-Klasse mit hoher Performance und gespiegelten Systemen. Auslastungsoptimierung bedeutet hier stets, zu überwachen, dass hinreichend Server- und Speichersystemkapazität für das Erfassungswachstum vorhanden sind, jedoch auch zu prüfen, welche Daten auf diesen Systemen zur Gewährleistung direkter Zugreifbarkeit gelagert werden müssen, und sicherzustellen, dass Daten späterer Informationslebenszyklusphasen auf weniger kostenintensive Medien migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von tiered IT-Plattformen. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Erstellungsphase bedeutet, dass die IT die Geschäftsprozesse der Erstellungsphase in IT-Prozesse umsetzen kann. Hier ist die IT als Prozesspartner des Unternehmens gefragt. Wenn Hardware- und Softwareinfrastruktur die in der Erstellungsphase zur Erfüllung ihrer Strategien benötigten Systemkomponenten bereitstellen, so muss hier die Prozesskette gemäß dem ITILService-Management bereitgestellt werden. Für die Compliance sind automatisierte Business-Intelligence-Prozesse vonnöten, die beispielsweise den Weg der Information durch die Lebenszyklusphasen steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt.

Abb. 2.12. Wiederverwendungswahrscheinlichkeit von Daten

36

2 Information Lifecycle und Information Lifecycle Management

Tabelle 2.3. IT-Strategien für die Erstellungsphase Strategienfeld

Strategie

Softwareinfrastruktur

Datenerstellung vor Ort ermöglichen. Lokale Erfassungssoftware am Ort der Informationsentstehung bereitstellen. Sicherstellung, dass bei Störung der Verbindung zur/der zentralen IT dennoch Datenerstellung möglich ist (asynchroner Abgleich mit zentraler IT). Bereitstellung eines geschäftskritischen OLTP-Systems. Bereitstellung eines hochverfügbaren CRM-Systems. Bereitstellung eines hochverfügbaren ERP-Systems. Bereitstellung performanter Datenbankmanagementsysteme mit Schutz vor Mehrfacherfassungen (regelbasiert, triggerbasiert). Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software).

Hardwareinfrastruktur

Bereitstellung vorkonfigurierter Erfassungshardware und Netzwerkinfrastruktur. Bereitstellung (hochverfügbarer) Serversysteme (eventuell der Enterprise-Klasse) in der zentralen IT. Eventuell Bereitstellung von Clustersystemen. Bereitstellung hochverfügbarer Speichersysteme (eventuell der Enterprise-Klasse) im SAN oder NAS. Bereitstellung eines qualitätsgesicherten Backup-/Restore-Verfahrens.

Prozessinfrastruktur

Bereitstellung eines ITIL konformen Service-Management. Mindestens Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business-Intelligence-Lösung. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informations- Implementierung der Strategien zu Software-, Hardware- und Prozesswertanpassung infrastruktur.

Diese Prozesse in Verbindung mit den „tiered“ Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz stellen die Strategie für die Informationswertanpassung in der Erstellungsphase dar. Wie wichtig der korrekte Strategien Mix für die Erstellungsphase ist, mag die Entwicklung der weltweit generierten Daten zeigen. Alle im Unternehmen anfallenden Daten können durch eine bedarfsgerechte Aufarbeitung aussagekräftige Informationen hervorbringen. Mit Hilfe dieser Informationen ist das Management schließlich in der Lage, die Erreichung bereits festgelegter Ziele zu überwachen, Entscheidungen auf fundierter Basis zu treffen und Verbesserungen für die Zukunft zu planen. Eine wesentliche Methode der Informationsdarstellung auch für das Objekt Information sind Kennzahlen. Sie

2.3 Der Informationslebenszyklus-Strategien-Mix

37

Abb. 2.13. Datenerstellung in 2006

ermöglichen es, eine Menge von messbaren, entscheidungsrelevanten Daten nach festgelegten Kategorien zu bündeln und in einem größeren, unternehmerischen Zusammenhang überschaubar und aussagefähig darzustellen. Eine wichtige Größe in Bezug auf ILM ist die mehrfache Nutzung der Daten im Sinne einer Zweit-, Dritt- bzw. Mehrfachbenutzung bereits erzeugter Daten. Natürlich könnte man hier auf den Gedanken kommen, erheblich Kosten im Bereich der Speicherung, des Backups und der Archivierung von Informationen zu sparen, wenn man Information als Wegwerfgut mit Einmalcharakter auffassen würde. Die beschriebenen spezifischen rechtlichen Anforderungen sollten bereits dieses Ansinnen im Ansatz desavouieren. Aus betriebwirtschaftlicher Sicht muss es das Ziel eines jeden Unternehmens sein, eine bereits erstellte Information möglichst häufig im internen Wertschöpfungsprozess zu verwenden. Wer kennt nicht aus seinem persönlichen Arbeitsumfeld zahllose Beispiele, in denen die weit verbreitete Nonchalance bei der Ablage dazu führt, dass wertvolle Arbeitszeit für die Wiederherstellung bereits erstellter Information verschwendet wird, nur weil die Suche in der Ablage zu umständlich ist. Laut der Second Study on Digital Data Creation der University of California, Berkeley19 werden weltweit im Jahr 2006 über 5 Exabytes an Daten neu erstellt.

 19

Moore, Fred: Storage New Horizons, Boulder, 2006, S. 8.

38

2 Information Lifecycle und Information Lifecycle Management

Dabei werden diese Daten von derzeit 4 Hauptplattformen aus erzeugt. Systeme mit dem Betriebssystem z/OS, also die klassischen z/Series Mainframes, erzeugen ca. 4 Prozent der Daten im Jahre 2006 mit einer jährlichen Wachstumsrate von 45 Prozent. Unix dominiert heute die Erzeugung digitaler Daten mit einem Bestand von 47 Prozent und einer Wachstumsrate von 63 Prozent. Microsoft Windows-Systeme erzeugen 38 Prozent der Daten mit einer Wachstumsrate von ebenfalls 63 Prozent. Das Betriebssystem mit dem höchsten Wachstum von 102 Prozent stellt Linux dar, das heute bereits mit 7 Prozent an der Datenerzeugung beteiligt ist. Andere Betriebssysteme mit einem Anteil von 4 Prozent an der Erzeugung digitaler Daten und einer Wachstumsrate von 31 Prozent können nahezu vernachlässigt werden. Dabei werden die heute digital erzeugten Daten zu 20 Prozent auf Festplatten (Magnetplatten) und zu 80 Prozent auf Wechselmedien (Magnetbänder und optische Medien) gespeichert. Abbildung 2.14 zeigt die Entwicklung des digitalen Speicherbedarfs im Verlauf des ersten Jahrzehnts des 21. Jahrhunderts. Dabei fällt auf, dass die Entwicklung der Datenerzeugung und -speicherung der klassischen Anwendungen für Online Transaction Processing (OLTP) und Entscheidungsunterstützung (Decision Support, DS) zwar exponentiell steigend ist, jedoch signifikant von der Entwicklung der Datenerzeugung durch neue digitale Applikationen überflügelt wird. Diese neuen Applikationen sind: x Fixed-Content-Anwendungen, das sind Applikationen, die nicht veränderbare Daten verwalten. Hier handelt es sich im Wesentlichen um Anwendungen rund um das Thema Archivierung. x E-Finance-Anwendungen wie Electronic Banking, Anwendungen für den Lieferanten/Kunden-Kontakt von Online-Banken, Online-Brokern und OnlineVersicherungen. x Wissenschaftliche/GIS-Anwendungen. Wissenschaftliche Anwendungen wie Simulationen (klassisch meteorologische Vorhersagen, Crashtests etc.), Auswertungen von Massendaten (astronomische Daten aus Satellitenmessungen, Hubble-Teleskop, erdgebundenen Teleskopen) etc. produzieren und verwalten mit jedem Technologieschritt in der Erfassungstechnologie steigende Datenmengen. Geographical Information Systems (GIS-) Anwendungen werden in zunehmenden Maß bei dem Gebrauch von Navigationssystemen zur Fahrzeugsteuerung und -überwachung sowie der Energieversorgung und der Telekommunikation eingesetzt (z. B. bei der Leitungsortung), aber auch im klassischen Freizeitbereich bei neuen Hobbies wie dem Geo-Caching. x Anwendungen der E-Medizin/Bildverarbeitung. Hierbei handelt es sich um Applikationen wie beispielsweise die digitale Krankenakte, die sämtliche Informationen für Arzt-/Patientenkontakte sowie Apotheken-/Patientenkontakte und deren Abrechnung enthält, oder die Anwendung von Computerund Magnetresonanz-Tomographie oder anderer bildgebender medizinischer Verfahren, die Unmengen an Daten produzieren, die auch gesetzlich reguliert über größere Zeiträume digital vorgehalten werden müssen.

2.3 Der Informationslebenszyklus-Strategien-Mix

39

Abb. 2.14. Entwicklung des Speicherbedarfs20

x E-Mail und Video-Mail. Für das Jahr 2007 wird erwartet, dass allein 400 PB (400 u 1024 u 1015 Bytes) an E-Mails generiert und gespeichert werden.21 Damit ist dies der Anwendungsbereich, der die höchste Datengenerierungs- und Wachstumsrate besitzt. x Digital-Security-Anwendungen sind Applikationen, die die Sicherheit in digitalen Netzen gewährleisten. Sicherheit bezieht sich dabei immer auf alle vier Säulen des Datenschutzes: Integrität, Authentizität, Vertraulichkeit und Verfügbarkeit. Die aktuellen Fortschritte in der Informationstechnologie ermöglichen es, immer komplexere Geschäftsprozesse über das Internet abzuwickeln. Sicherheitsaspekte spielen heute eine zentrale Rolle für die Akzeptanz webbasierter Geschäftsmodelle. Die Anwendungen im Bereich digitaler Security implementieren Strategien und Lösungen, um die Sicherheit des Datentransfers zu gewährleisten. Dazu gehören Techniken wie digitale Signatur, Chipkartentechnologie, Prozessautomation gemäß BSI-Sicherheitsstandards sowie Sicherheitstechniken zum E-Commerce. x Unterhaltungsanwendungen wie Video- und Audio-on-Demand, Downloads von MP3s, iPod etc. Der Strategien-Mix in der Verdichtungs- und Nutzungsphase wird implementiert, indem bei der Softwareinfrastruktur die erzeugten Daten beständig den  20 21

Moore, Fred: Storage New Game New Rules, Boulder, 2003, S. 10. Moore, Fred: Storage New Horizons, a.a.O., S. 8.

40

2 Information Lifecycle und Information Lifecycle Management

existierenden Geschäftsanwendungen verfügbar gemacht werden. Gemäß der Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten ist in diesen beiden Phasen die Wahrscheinlichkeit, dass eine einmal erfasste Information wieder verwendet wird, am größten. Ein Beispiel ist der Telefoniekunde, der im Shop seiner Telefongesellschaft einen neuen Vertrag abgeschlossen hat. Nun muss sichergestellt sein, dass seine Telefonnummer möglichst sofort freigeschaltet wird, so dass er seinen neuen Vertrag auch nutzen kann. Ist die Telefongesellschaft eventuell in einen Konzern eingebunden, können die Daten des Neukunden mit den Bestandsdaten abgeglichen werden. Es kann geprüft werden, ob dieser Kunde tatsächlich Neukunde für den Konzern ist – dann bietet es sich an, ihm auch die übrigen Produkte des Konzerns nahezubringen –, falls nein, kann sichergestellt werden, dass dieser Kunde alle Angebote konsistent aus einer Hand bekommt, indem er, falls er dies wünscht, lediglich eine Rechnung über die Nutzung sämtlicher Produkte des Unternehmens bzw. des Konzerns erhält. Die Softwareinfrastruktur muss den zeitnahen Abgleich der Daten des „Konzernkunden“ mit der zentralen IT sicherstellen. In der zentralen IT müssen seitens der Softwareinfrastruktur ein geschäftskritisches OLTP-System, performante Datenbankmanagementsysteme, ein 24 u 7 verfügbares CRM- und ERP-System vorhanden sein. Der Zugriff des Kunden auf die von ihm vertraglich erworbenen Services ist störungsfrei zu gewährleisten. Sicherheitsmechanismen für die digitale Sicherheit müssen automatisiert greifen, Business-Intelligence-Lösungen für die Gewährleistung der Compliance müssen automatisiert durchgeführt werden. Hier lassen sich als Beispiel die Anforderungen des Telekommunikationsgesetzes TKG 2004 § 96 Absatz (2) anführen, das fordert, dass sämtliche Verkehrsdaten mit Ausnahme der in TKG 2004 § 96 Absatz (2) genannten nach Beendigung einer Verbindung des Kunden automatisch gelöscht werden. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert hier ein Release-Management, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Ferner muss gewährleistet sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. Idealerweise steht für den Betrieb der IT-Umgebung für die Verdichtungs- und Nutzungsphase eine Software zur Verfügung, die den Service Support (zumindest Incident-, Problem- und Change-Management) für die zentralisierte IT unterstützt. Eine Systemmanagementumgebung, die die komplette Infrastruktur (Primär-, Sekundär- und Tertiärtechnik) steuert und überwacht (beispielsweise Tivoli oder zum Teil auch EMC2’s ECC), ist hier sinnvoll. Zur Gewährleistung der permanenten Verfügbarkeit und Business Continuity auch im Störungsfall sind ClusterSoftwareeinsatz, Softwareunterstützung von lokalen und remote MirroringVerfahren, Daten-Cloning und Snapshots unabdingbar. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Verdichtungs- und Nutzungsphase, dass eine zugriffsort-/zugriffszeit-/zugriffsrechtoptimierte Autorisierung vorliegt. Die RZ-Infrastruktur muss die hohen Anforderungen der Verdichtungs-/Nutzungsphase erfüllen. Hier wird hochver-

2.3 Der Informationslebenszyklus-Strategien-Mix

41

fügbare Server-, Clusterserver- und Speicherinfrastruktur benötigt. Die Wahrscheinlichkeit ist dabei sehr hoch, dass auf die Daten der Verdichtungs- und der Nutzungsphase sehr schnell wieder zugegriffen wird. Dies erfordert in dieser Phase IT-Primärtechnik der Enterprise-Klasse mit hoher Performance und gespiegelten Systemen. Auslastungsoptimierung bedeutet hier, stets zu überwachen, dass hinreichend Server- und Speichersystemkapazität für das Datenvolumen vorhanden sind, jedoch auch zu prüfen, welche Daten auf diesen Systemen zur Gewährleistung direkter Zugreifbarkeit gelagert werden müssen, und sicherzustellen, dass Daten späterer Informationslebenszyklusphasen auf weniger kostenintensive Medien migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „Tiered“-IT-Plattformen. Die Verdichtungs- und Nutzungsphase ist innerhalb dieser „Tiered“-IT-Plattform durch die Nutzung von „Primary“-System- und -Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Verdichtungs-/Nutzungsphase bedeutet, dass die IT die Geschäftsprozesse dieser beiden Phasen in IT-Prozesse umsetzen kann. Hier ist die IT als Prozesspartner des Unternehmens gefragt. Wird Hardware- und Softwareinfrastruktur mit den zur Erfüllung ihrer Strategien der Verdichtungs-/Nutzungsphase benötigten Systemkomponenten zur Verfügung gestellt, so muss hier die Prozesskette eines ITIL-Servicemanagement zur Verfügung gestellt werden. Gefragt sind hier zumindest die Prozesse für ein Incident-Management, bei dem über einen Service-Desk Fehler schnell zur Bearbeitung kanalisiert und Lösungen dokumentiert werden, die zur Lösung eines erneuten Fehlerfalles herangezogen werden können. Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, zu unerwarteten Ausfallzeiten oder sogar zu einem Datenverlust führen. Das ProblemTabelle 2.4. Attributausprägungen der Verdichtungs-/Nutzungsphase Attribut

Beschreibung

Betriebszeit

Montag bis Sonntag: 00:00 Uhr bis 24:00 Uhr

Betriebsnebenzeiten

Keine – Geplante Auszeiten terminiert nur alle 1 bis 3 Monate oder nach Abstimmung

Hardware-verfügbarkeit Maximal 14 Stunden Logische Wiederherstellung

Maximal 4 Stunden

Maximaler geplanter, d. h. maximal zulässiger Datenverlust

0 Minuten

Service-Desk

Ja, zu Betriebszeiten des Service-Desk

Reaktionszeiten

Maximal 15 Minuten für das Service-Desk Maximal 30 Minuten außerhalb der Betriebszeiten des Service-Desk

Bereitschaft

Ja außerhalb der Betriebszeiten des Service-Desk

42

2 Information Lifecycle und Information Lifecycle Management

Management muss die Fehlerhäufigkeiten überwachen, Schwachstellen ermitteln und diese über den Change-Management-Prozess beseitigen. Release-Management, Business-Continuity-Management und Configuration-Management sind ebenfalls von zentraler Bedeutung für die prozessuale Kompetenz in der Verdichtungs- und der Nutzungsphase. Letztlich sollte auch für eine interne IT ein SLA-Management sicherstellen, dass diese die genauen Anforderungen des Kerngeschäfts an die IT kennt, und die Erfüllung dieser Anforderungen strikt überwacht. Ein derartig ausgestalteter Servicemanagement-Prozesse degradiert die interne IT nicht zum austauschbaren Technologiepartner des Unternehmens, sondern macht sie zum wertvolleren Prozesspartner, dessen Produktionsprozesse verwoben sind mit den Geschäftsprozessen des Unternehmens.

Tabelle 2.5. IT-Strategien für die Verdichtungs-/Nutzungsphase Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung eines geschäftskritischen OLTP-Systems. Bereitstellung eines hochverfügbaren CRM-Systems. Bereitstellung eines hochverfügbaren ERP-Systems. Bereitstellung performanter Datenbankmanagementsysteme mit Schutz vor Mehrfacherfassungen (regelbasiert, triggerbasiert). Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesicherten Netzwerkinfrastruktur. Bereitstellung (hochverfügbarer) Serversysteme (eventuell der Enterprise-Klasse) in der zentralen IT. Eventuell Bereitstellung von Clustersystemen. Eventuell Bereitstellung von Spreaded-Clustersystemen zur Absicherung des K-Falls. Bereitstellung hochverfügbarer Speichersysteme (eventuell der Enterprise-Klasse) im SAN oder NAS. Bereitstellung remote gespiegelter Speichersysteme zur Absicherung des K-Falls. Bereitstellung eines qualitätsgesicherten Backup-/Restore-Verfahrens.

Prozessinfrastruktur

Bereitstellung eines ITIL-konformen Servicemanagement. Mindestens eine Prozessunterstützung in Form von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business-Intelligence-Lösung. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informations- Implementierung der Strategien zu Software-, Hardware- und Prozesswertanpassung infrastruktur.

2.3 Der Informationslebenszyklus-Strategien-Mix

43

Für die Compliance sind, wie bereits beschrieben, automatisierte BusinessIntelligence Prozesse vonnöten. Eine wichtige Aufgabe dabei ist, den Weg der Information durch die Lebenszyklusphasen zu steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. bereitzustellen. Diese in Verbindung mit den „Tiered“- Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz stellen die Strategie für die Informationswertanpassung in der Verdichtungs- und der Nutzungsphase dar. Der Strategien-Mix in der Bewahrungsphase wird implementiert, indem bei der Softwareinfrastruktur die erzeugten Daten zwar den existierenden Geschäftsanwendungen verfügbar gemacht werden, aber nicht mehr mit dem Aufwand und der Sicherheit, wie dies in den drei früheren Phasen des Produktlebenszyklus der Fall war. Hier werden hardwareseitig so genannte Nearline-Techniken als Gegensatz zu den Online-Techniken der ersten drei Informationslebenszyklusphasen eingesetzt. Dies spiegelt einerseits die Entwicklung der Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten wider (vgl. Abb. 2.12), die in der Phase der Bewahrung eine deutliche Abnahme der Wiederverwendungswahrscheinlichkeit anzeigt, als auch die Kurve des Wertes der Information für das Unternehmen (vgl. Abb. 2.7), die einen Anstieg des Wertes nur durch das Eintreten von Ausnahmesituationen darstellt, ansonsten jedoch die Bewahrungsphase bereits als Phase sinkenden Wertes der Information für die Geschäftsprozesse des Unternehmens sieht. Bleiben wir beim Beispiel unseres Telefoniekunden. Er hat seinen Vertrag gekündigt, die letzten Telefonate sind bereits abgerechnet und auch die sonstigen Gründe zur Aufbewahrung der Daten gemäß TKG 2004 § 96 Absatz (2) sind nicht mehr gegeben. Nun muss sichergestellt sein, dass noch sämtliche Informationen zu diesem Vertrag gemäß TKG 2004 § 111 (d. h. die Daten für die Auskunftsersuchen der Sicherheitsbehörden) gespeichert werden, die übrigen Daten dieses Telefoniekunden können, ja müssen gelöscht werden. Die Informationen Tabelle 2.6. Attributausprägungen der Bewahrungsphase Attribut

Beschreibung

Betriebszeit

Montag bis Sonntag: 00:00 Uhr bis 24:00 Uhr

Betriebsnebenzeiten

Keine; geplante Auszeiten terminiert, bei Bedarf häufiger als in Verdichtungs- und Nutzungsphase

Hardware-Verfügbarkeit

Maximal 12 Stunden

Logische Wiederherstellung

Maximal 24 Stunden

Maximaler geplanter Datenverlust

0 Minuten

Service-Desk

Ja, zu Betriebszeiten des Service-Desk

Reaktionszeiten

Maximal 4 Stunden zu Betriebszeiten des ServiceDesk

Bereitschaft

Nicht unbedingt erforderlich

44

2 Information Lifecycle und Information Lifecycle Management

gemäß TKG 2004 § 111 sind für die Telefongesellschaft und deren Geschäftserfolg von keinerlei Bedeutung mehr. Sie müssen lediglich aufgrund der gesetzlichen Anforderungen aufbewahrt werden und gewinnen nur dann nochmaligen Wert, wenn eine Sicherheitsbehörde eben diese Daten nachfragt – ein zugegebenermaßen vorkommender, jedoch eher seltener Fall. Derartige Daten fallen in der Bewahrungsphase an. Die Softwareinfrastruktur muss in der Bewahrungsphase einen zeitkonformen Abgleich mit den anfordernden Anwendungen der zentralen IT sicherstellen und in der zentralen IT müssen seitens der Softwareinfrastruktur die benötigten Anwendungen zur Verfügung gestellt werden. Der Zugriff des Unternehmens und der Berechtigten auf die benötigten Services muss zwar störungsfrei gewährleistet sein, jedoch nicht unbedingt sofort ermöglicht werden. Sicherheitsmechanismen für die digitale Sicherheit müssen

Tabelle 2.7. IT-Strategien für die Bewahrungsphase Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung des Zugriffs durch das geschäftskritische OLTP-System, das hochverfügbare CRM-System und das hochverfügbare ERPSystem der Vorphasen. Bereitstellung des Zugriffs durch die performanten Datenbankmanagementsysteme der Vorphasen. Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesicherten Netzwerkinfrastruktur. Bereitstellung ausreichend dimensionierter Serversysteme in der zentralen IT. Absicherung des K-Falls durch geeignete Datenauslagerungs- oder Remote-Backup-Verfahren. Bereitstellung (hochverfügbarer) Speichersysteme im SAN oder im NAS. Bereitstellung eines qualitätsgesicherten Backup-/Restore-Verfahrens.

Prozessinfrastruktur

Bereitstellung eines ITIL-konformen Servicemanagements. Mindestens jedoch eine Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business-Intelligence-Lösung. Bereitstellung von Migrationsprozessen zur Überführung der Daten aus den Vorphasen in die Software- und Hardwareinfrastruktur der Bewahrungsphase. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informations- Implementierung der Strategien zu Software-, Hardware- und Prowertanpassung zessinfrastruktur.

2.3 Der Informationslebenszyklus-Strategien-Mix

45

automatisiert greifen, Business-Intelligence-Lösungen für die Gewährleistung der Compliance müssen automatisiert durchgeführt werden. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert hier ein Release-Management, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Außerdem muss dafür gesorgt werden, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. Idealerweise steht auch für den Betrieb der IT-Umgebung für die Bewahrungsphase eine Software zur Verfügung, die den Service-Support (zumindest Incident-, Problem- und Change-Management) für die zentralisierte IT unterstützt. Eine Systemmanagementumgebung, die die komplette Infrastruktur (Primär-, Sekundär- und Tertiärtechnik) steuert und überwacht (beispielsweise Tivoli oder z. T. auch EMC2’s ECC), ist hier ebenfalls sinnvoll, jeweils angepasst an die reduzierte Verfügbarkeitsanforderung und die Wertigkeit der Daten. Hierbei sind die Alarmierungs- und Eventzyklen größer. Eine permanente Ad-hoc-Verfügbarkeit und Business-Continuity auch im Störungsfall ist nicht mehr gefordert. Daher ist ein Cluster-Softwareeinsatz nicht mehr und die Softwareunterstützung von lokalen und remote Mirroring Verfahren, Daten-Cloning und Snapshots nur noch bedingt erforderlich. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Bewahrungsphase, dass Daten von der kostenintensiven Primärtechnik auf preiswertere Sekundärtechnik migriert werden müssen. Die RZ-Infrastruktur wird an die gesunkene Wiederverwendungswahrscheinlichkeit und den gesunkenen Informationswert angepasst. Hier wird keine hochverfügbare ServerCluster und Speicherinfrastruktur mehr benötigt. Dies erfordert in dieser Phase IT-Sekundärtechnik der Midrange-Klasse mit ausreichender Performance und nur in Ausnahmefällen noch lokal gespiegelten Daten. Auslastungsoptimierung bedeutet hier, stets zu überwachen, dass auf der Sekundärtechnik hinreichend Server- und Speichersystemkapazität für das Datenvolumen vorhanden sind, jedoch im Wesentlichen zu prüfen, welche Daten von der Primärtechnik der Enterprise-Klasse auf diese Systeme migriert werden müssen. Ferner gilt es, sicherzustellen, dass Daten der Archivierungsphase, also Daten, die nicht mehr für eventuell geschäftsvorfallnahe Verarbeitung benötigt werden, auf die am wenigsten kostenintensiven Medien der Archivierungsphase migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „Tiered“-IT-Plattformen. Die Bewahrungsphase ist innerhalb dieser „Tiered“-ITPlattform durch die Nutzung von „Secondary“-System- und -Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Bewahrungsphase bedeutet, dass die IT die Geschäftsprozesse der beiden Vorläuferphasen in IT-Prozesse reduziert, die lediglich die bewahrende Sicherung und den Nearline-Zugriff auf die Daten dieser Phase ermöglichen. Hier ist die IT wiederum als Prozesspartner des Unternehmens gefragt. Wenn Hardware- und Softwareinfrastruktur die zur Erfüllung ihrer Strategien

46

2 Information Lifecycle und Information Lifecycle Management

der Bewahrungsphase benötigten Systemkomponenten bereitstellen, so muss hier vor allem die Kenntnis der Geschäftsprozesse die Migration zumindest automatisiert initiieren. Die Prozesskette des ITIL Service-Management der vorangehenden Phasen wird weiter genutzt. Notwendig ist zumindest der Prozess für ein Incident-Management, bei dem über einen Service-Desk-Fehler schnell zur Bearbeitung kanalisiert und Lösungen dokumentiert werden, die zur Beseitigung eines erneuten Fehlerfalles herangezogen werden können. Das Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeiten oder gar zu einem Datenverlust führen. Das Problem-Management muss die Fehlerhäufigkeit überwachen, die Schwachstellen ermitteln und diese über den ChangeManagement-Prozess beseitigen. Release-Management, Business-ContinuityManagement und Configuration-Management sind ebenfalls von zentraler Bedeutung für die prozessuale Kompetenz in der Bewahrungsphase. Letztlich sollte auch für eine interne IT ein SLA-Management sicherstellen, dass die Anforderungen der Kernprozesse an die IT in der Bewahrungsphase bekannt sind und die Erfüllung der beschriebenen Anforderungen strikt überwacht wird. Dieses Kostenbewusstsein mit dem Ziel der Senkung der TCO durch datenwertorientierte Datenhaltung bindet die interne IT in die Geschäftsprozesse des Unternehmens ein. Hier sind Prozesse zur Benutzerautorisierung, zum Datenschutz, zur Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt. Diese stellen in Verbindung mit den „Tiered“-StorageSystemen als Realisierung für die Hardwareinfrastruktureffizienz ebenfalls die Strategie für die Informationswertanpassung in der Bewahrungsphase dar. Der Strategien-Mix in der Archivierungsphase bedeutet für die Softwareinfrastruktur, die erzeugten Daten lediglich als „Fixed“-Content, also nicht mehr

Tabelle 2.8. Attributausprägungen der Archivierungsphase Attribut

Beschreibung

Betriebszeit

Montag bis Sonntag: 00:00 Uhr bis 24:00 Uhr

Betriebsnebenzeiten

Keine – Geplante Auszeiten terminiert, bei Bedarf häufiger als in Bewahrungsphase

Hardwareverfügbarkeit

Maximal 24 Stunden

Logische Wiederherstellung

Maximal 48 Stunden

Maximaler geplanter, d. h. zulässiger Datenverlust

0 Minuten

Service-Desk

Empfehlenswert

Reaktionszeiten

Maximal 4 Stunden zu Betriebszeiten

Bereitschaft

Nicht unbedingt erforderlich

2.3 Der Informationslebenszyklus-Strategien-Mix

47

änderbar, über Archivierungssoftware speicher- und wieder auffindbar zu machen. Dies verursacht einen weitaus geringeren Aufwand bei hoher Sicherheit, der dadurch erkauft wird, dass die Daten nicht mehr online oder nearline zugreifbar sind, wie es in den früheren Phasen des Produktlebenszyklus der Fall war. Hier werden hardwareseitig Magnetbandarchivierungen und Content Adressable Storage (CAS-) Magnetplattensysteme für langfristige Aufbewahrungsfristen eingesetzt. Dies spiegelt einerseits die Entwicklung der Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten wider, die in der Phase der Archivierung eine deutlich niedrigere Wiederverwendungswahrscheinlichkeit der Daten anzeigt, als auch die Kurve des Informationswertes für das Unternehmen (vgl. Abb. 2.7), die eine starke Degression des Wertes der Information für die Geschäftsprozesse des Unternehmens sieht. Bleiben wir beim Beispiel unseres Telefoniekunden. Er hat seinen Vertrag gekündigt, die letzten Telefonate sind bereits abgerechnet und auch die sonstigen Gründe zur Aufbewahrung der Daten gemäß TKG 2004 § 96 Absatz (2) und TKG 2004 § 111 (Daten für Auskunftsersuchen der Sicherheitsbehörden) (TKG 1996 § 90) sind nicht mehr gegeben. Nun muss lediglich noch sichergestellt sein, dass sämtliche geschäftsvorfallbezogenen Dokumente zu diesem Vertragsverhältnis dokumentenecht gespeichert werden, bis die Aufbewahrungsfrist nach HGB, KonTrAG usw. abgelaufen ist. Diese Informationen sind für die Telefongesellschaft und deren Geschäftserfolg von keinerlei Bedeutung mehr. Sie müssen lediglich aufgrund der gesetzlichen Anforderungen aufbewahrt werden und gewinnen nur dann nochmaligen Wert, wenn über ein Audit oder eine Revision eben diese Daten nachgefragt werden – ein durchweg seltener Fall. Von solcher Form sind die Daten der Archivierungsphase. Die Softwareinfrastruktur muss in der Archivierungsphase eine dokumentenechte Abspeicherung der zu archivierenden Daten und eine dokumentenechte Wiederherstellung zu jedem Zeitpunkt der Archivierungsdauer sicherstellen. In der zentralen IT müssen seitens der Softwareinfrastruktur die benötigten Anwendungen zur Archivierung und zum Retrieval zur Verfügung gestellt werden. Der Zugriff des Unternehmens und der Berechtigten auf die benötigten Services muss zwar störungsfrei gewährleistet sein, jedoch nicht unbedingt sofort ermöglicht werden. Sicherheitsmechanismen für die digitale Sicherheit müssen automatisiert greifen und Business-Intelligence-Lösungen für die Gewährleistung der Compliance müssen automatisiert durchgeführt werden. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert auch hier ein ReleaseManagement, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Außerdem muss sichergestellt sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. Idealerweise steht auch für den Betrieb der IT-Umgebung für die Archivierungsphase eine Software zur Verfügung, die den Service Support (zumindest Incident-, Problem- und Change-Management) für die zentralisierte IT unterstützt. Eine Systemmanagementumgebung, die die komplette Infrastruktur (Primär-, Sekundär- und Tertiärtechnik) steuert und überwacht (beispielsweise

48

2 Information Lifecycle und Information Lifecycle Management

Tivoli oder z. T. auch EMC2’s ECC), ist hier ebenfalls sinnvoll, jedoch, angepasst an die reduzierte Verfügbarkeitsanforderung an die Daten und deren Wertigkeit sind hier die Alarmierungs- und Eventzyklen wesentlich größer. Eine permanente Ad-hoc-Verfügbarkeit und Business-Continuity auch im Störungsfall ist nicht mehr gefordert. Daher ist ein Cluster-Softwareeinsatz nicht mehr und die Softwareunterstützung von lokalen und remote Mirroring-Verfahren, DatenCloning und Snapshots nur noch bedingt über die Steuerungs- und Administrationssoftware der eingesetzten Archivierungshardware erforderlich. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Archivierungsphase, dass Daten von der kostenintensiven Primär- und/oder Sekundärtechnik auf preiswerte Archivierungstechnik migriert werden müssen. Die RZ-Infrastruktur wird an die gesunkene WiederverwendungswahrscheinTabelle 2.9. IT-Strategien für die Archivierungsphase Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung von Fixed-Content-Archivierungs- und -Dearchivierungssoftware. Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesicherten Netzwerkinfrastruktur. Bereitstellung ausreichend dimensionierter Serversysteme in der zentralen IT zur Archivierung und Dearchivierung. Absicherung des Katastrophenfalls durch geeignete Datenauslagerungs- oder Remote-Backup-Verfahren. Bereitstellung (hochverfügbarer) Content Adressable Storage (CAS) oder archivierungssicherer Tape-Systeme. Bereitstellung eines qualitätsgesicherten Backup-/RestoreVerfahrens.

Prozessinfrastruktur

Bereitstellung eines ITIL-konformen Servicemanagement. Mindestens Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business-Intelligence-Lösung. Bereitstellung von Migrationsprozessen zur Überführung der Daten aus den Vorphasen in die Software- und Hardwareinfrastruktur der Archivierungsphase. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informationswertanpassung

Implementierung der Strategien zu Software-, Hardware- und Prozessinfrastruktur.

2.3 Der Informationslebenszyklus-Strategien-Mix

49

lichkeit und den gesunkenen Informationswert angepasst. Hier wird keine hochverfügbare Server-, Cluster- und Speicherinfrastruktur mehr benötigt. Dies erfordert in dieser Phase IT-Archivierungstechnik für „Fixed“-Content mit automatisiert gespiegelten SATA-Platten oder Magnetbandbibliotheken mit den jeweils notwendigen Umkopierungsaktivitäten bei Medien- oder SoftwareReleasewechseln. Auslastungsoptimierung bedeutet hier, stets zu überwachen, dass auf der Archivierungstechnik hinreichend Server- und Speichersystemkapazität für das Datenvolumen vorhanden sind, jedoch im Wesentlichen zu prüfen, welche Daten von der Primärtechnik der Enterprise-Klasse und der Sekundärtechnik der Midrange-Klasse auf diese Systeme migriert werden müssen. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „Tiered“-IT-Plattformen. Die Archivierungsphase ist innerhalb dieser „Tiered“-IT-Plattform durch die Nutzung von Archivierungssystem- und Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Archivierungsphase bedeutet, dass die IT die Geschäftsprozesse zur Archivierung in IT-Prozesse reduziert, die lediglich die dokumentenechte Langzeitspeicherung und die dokumentenechte Wiederherstellung dieser Daten ermöglichen. Hier ist die IT wiederum als Prozesspartner des Unternehmens gefragt, um gemäß den Geschäftsprozessen die Migration zumindest automatisiert zu initiieren und eventuell projektorientiert durchzuführen. Die Prozesskette des ITIL-konformen Servicemanagement der vorangehenden Phasen wird weiter genutzt. Gefragt sind hier noch immer die Prozesse für ein Incident-Management, bei dem über einen Service-Desk Fehler schnell zur Bearbeitung kanalisiert und Lösungen dokumentiert werden, die bei der Behebung eines erneuten Fehlerfalles herangezogen werden können. Ein Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeiten oder sogar Datenverlust führen. Das Problem-Management muss die Fehlerhäufigkeiten überwachen, Schwachstellen ermitteln und diese über den Change-Management-Prozess beseitigen. ReleaseManagement, Business-Continuity-Management und Configuration-Management sind ebenfalls von Bedeutung für die prozessuale Kompetenz in der Archivierungsphase. Letztlich sollte auch für eine interne IT ein SLA-Management sicherstellen, dass diese genau weiß, welche Anforderungen das Kerngeschäft an die IT in der Archivierungsphase hat, und die Erfüllung dieser Anforderungen strikt überwacht. Dieses Kostenbewusstsein mit dem Ziel der Senkung der TCO durch datenwertorientierte Datenhaltung bindet die interne IT in die Geschäftsprozesse des Unternehmens ein. Zusätzlich sind automatisierte Business-Intelligence-Prozesse vonnöten. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt. Diese stellen in Verbindung mit den „Tiered“-Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz ebenfalls die Strategie für die Informationswertanpassung in der Archivierungsphase dar. Die Complianceanforderungen bezüglich der langfristigen Speicherung und Aufbewahrung geschäftsvorfallrelevanter Informationen sorgen für einen im-

50

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.15. Die Entwicklung des Speicherbedarfs

mensen Anstieg der gesamten zu speichernden (und wiederzugewinnenden) Datenmenge. So sind die gemäß Sarbanes-Oxley-Act und diverser anderer Gesetzgebungen (siehe unten jeweils in Klammern) für die USA definierten Aufbewahrungszeiten unterschiedlicher Informationen beträchtlich. Sämtliche Informationen bezogen auf die Herstellung, Verarbeitung und Verpackung von Lebensmitteln müssen für mindestens zwei Jahre nach Verkauf aufbewahrt werden (Pharmaceutical/Life sciences 21 CFR Part II). Die Daten zu Herstellung, Verarbeitung und Verpackung von Drogeriewaren und Waren der pharmazeutischen Industrie müssen mindestens 3 Jahre nach Auslieferung aufbewahrt werden (Pharmaceutical/Life sciences 21 CFR Part II). Herstellungsdaten biologischer Produkte müssen 5 Jahre nach Herstellungsende archiviert werden (Pharmaceutical/Life sciences 21 CFR Part II). Sämtliche fallspezifischen Informationen aus Krankenhäusern müssen 5 Jahre archiviert werden (Health Care HIPAA). Medizinische Daten von Minderjährigen müssen 21 Jahre aufbewahrt werden (Health Care HIPAA). Sämtliche Patientendaten müssen bis 2 Jahre nach dem Tod eines Patienten archiviert werden (Health Care HIPAA). x Im Bereich der Finanzinstitute müssen nach SEC 17a-4 sämtliche Kontenbewegungen für drei Jahre, die Zulassungen für Broker (Makler) und Dealer (Händler) müssen bis zur Liquidation des Handelshauses oder der Firma des Maklers und Händlers aufbewahrt werden. Sämtliche Transaktionen eines Kunden eines Händlers oder Maklers müssen 6 Jahre nach Abschluss der letzten Transaktion dieses Kunden aufbewahrt werden.

2.3 Der Informationslebenszyklus-Strategien-Mix

51

x Die Occupational Safety and Health Administration (OSHA) regelt den Umgang mit Daten geprüfter Personen, die Kontakt zu toxischen Substanzen haben. Die Daten dieses Personenkreises müssen noch bis zu 30 Jahre nach dem OSHA-Audit der Person aufbewahrt werden. x Der Sarbanes-Oxley-Act fordert die dokumentenechte Aufbewahrung jeglicher Dokumente aus der Rechnungsprüfung von börsennotierten Unternehmungen für mindestens 4 Jahre nach Abschluss der Prüfung. x Diese Entwicklung sorgt für einen exponentiellen Verlauf der Kurve der archivierten Daten (vgl. Abb. 2.15) mit einer Steigerungsrate von jährlich über 60 Prozent, während die auf primären und sekundären Speichersystemen gespeicherten und administrierten Datenmengen hingegen relativ moderat mit lediglich etwas mehr als 20 Prozent Steigerungsrate ansteigen. Dies zeigt, dass trotz der immensen Menge der zu speichernden Daten der Erfassungs-, Verdichtungs- und Nutzungsphase des Informationslebenszyklus eine weitaus größere Herausforderung in der Datenflut der Bewahrungs- und Archivierungsphase liegt. Abbildung 2.16 setzt diese Steigerungsrate der gespeicherten und archivierten Datenmengen in Relation zu der Wiederverwendungshäufigkeit der Daten. Diese Relation zeigt wiederum deutlich, dass die Wiederverwendungshäufigkeit des weitaus größten Teils der gespeicherten Daten relativ gering ist. Dies deutet darauf hin, dass Daten mit geringem operativem Wert für das Unternehmen den weitaus größten Teil des Speicherbedarfs darstellen. Hier muss aus TCO-Sicht

Abb. 2.16. Wiederverwendungswahrscheinlichkeit-Datenmenge-Relation

52

2 Information Lifecycle und Information Lifecycle Management

(Total-Cost-of-Ownership) mit Projekten angesetzt werden, die die Speicherkonsolidierung dahingehend betreiben, dass die zu bewahrenden und zu archivierenden Datenmengen auf Tertiär-Speichertechnologien migriert werden und nicht länger die teuren Primär- und Sekundär-Speichertechnologien nutzen. Primär-Speichertechnologien (Tier 1 Storage) sind gekennzeichnet durch x Magnetplatten(-systeme) der Enterprise-Klasse (HDS TagmaStore, EMC2 Symmetrix DMX etc.), x hochperformante Speicheranwendungen (beispielsweise EMC2 TimeFinder, SRDF usw.), x Mirroring und Replikation, x synchrone und asynchrone Spiegelung; diese werden eingesetzt in den Informationlebenszyklusphasen der Erstellung, der Verdichtung und der Nutzung und bedienen vor allem die so genannten Mission-critical-Anwendungen wie hochperformante OLTP-Systeme, CRM- und ERP-Systeme. Sekundär-Speichertechnologien (Tier 2 Storage) setzen auf x Midrange-Magnetplatten(-systeme) (beispielsweise EMC2 CLARiiON, SUN/ Storagetek FLX-Systeme, IBM DS8xxx Speichersysteme etc.) eventuell mit günstiger SATA-Technologie und Disk-Libraries (virtuelle Magnetbänder), x Point-in-Time-Replikationen und Snapshots werden für unveränderliche Daten aus den ersten Informationslebenszyklus-Phasen, für die Daten der Bewahrungsphase sowie für Backup und Recovery sowie als Referenzdaten verwendet. Tertiär-Speichertechnologien (Tier 3 Storage) werden verwendet für x die langfristige Aufbewahrung von Daten für die gemäß Archivierungsvorschriften zu archivierenden unveränderlichen Daten der Archivierungsphase des Informationslebenszyklus, x Audio-, Video- oder Mediziendaten sämtlicher Lebenszyklusphasen; x Content Adressable Storage (CAS ; hier z. B. EMC2 CENTERA), x Magnetbandbibliotheken, Deep Archive, x optische Speichermedien. Die Umsetzung der IT-Strategien für sämtliche Phasen des Informationslebenszyklus wird durch die IT-Industrie im Allgemeinen und die Speicherindustrie im Besonderen durch Bereitstellung der entsprechenden Produkte und Dienstleistungen unterstützt. Die Umsatzentwicklung der Speicherindustrie trägt bereits heute der Entwicklung zum Information Lifecycle Management durch die Implementierung der IT-Strategien Rechnung. So waren 2004 die Dienstleistungen im Speichermarkt mit einem Jahresumsatz von 24,9 Milliarden US-Dollar bereits der mit Abstand größte Umsatzträger der Speicherindustrie. Diese Dienstleistungen sind heute im Wesentlichen solche, die die Implementierung von „Tiered“-Storage-Technologien unterstützen, also Services, die bei

2.3 Der Informationslebenszyklus-Strategien-Mix

53

der Implementierung der Prozessinfrastruktur und der Informationswertanpassung für sämtliche Phasen des Informationslebenszyklus helfen. Die Umsätze für Speichersoftware haben im vergangenen Jahrzehnt immens zugenommen (2004 betrug der Jahresumsatz 7,8 Milliarden US-Dollar, der auch in 2005 und 2006 weiter stark anstieg). Die Software ist für die direkte Steuerung und die Performance-Steigerung der Speichersysteme (Micro- und Flarecodes) sowie deren Spiegelung im Einsatz und umfasst auch Business-ContinuitySoftware. Mit jährlichen Wachstumsraten von über 30 Prozent tragen heute jedoch integrierte Administrationsapplikationen zu dem Speichersoftwareumsatz bei. Diese unterstützen die IT-Strategien zur Softwareinfrastruktur über sämtliche Phasen des Informationslebenszyklus. Die Umsätze für Speicherhardware unterteilen sich im Jahr 2004 in 20,6 Milliarden US-Dollar für Platten-Speichersysteme (sowohl Tier-1- und Tier-2 als auch die CAS-Systeme der Tier-3-Speichertechnologie), 2 Milliarden US-Dollar für Fiber-Channel Switches, Direktoren und Host-Bus-Adapter sowie 4,3 Milliarden US-Dollar für die Magnetbandautomation (Libraries) für sämtliche Phasen des Informationslebenszyklus. Diese Techniken stellen das Reservoir für die phasenkonforme Implementierung der Hardwareinfrastruktur dar. Betrachtet man im folgenden Abschnitt die Informationswert-Aufbewahrungszeit-Matrix als Visualisierung der Portfolioanalyse des Informationsmanagements eines Unternehmens, so definieren der IT-Strategien-Mix über die Phasen des Informationslebenszyklus sowie die angebotenen Technologien und Services zu dessen Implementierung das durch die Gegebenheiten geforderte Vorgehen zum Information Lifecycle Management. Allein eine TCO-Betrachtung über sämtliche Phasen des Informationslebenszyklus fordert von einer IT, die Erfolgspartner ihres Unternehmens sein will, Information Lifecycle Management zu implementieren. Als Prozesspartner des Unternehmens ist sie allein zur Unterstützung der legislativen Anforderungen an die Datenhaltung, wie wir sie im Anschluss an die Informationswert-Aufbewahrungszeit-Matrix darstellen werden, gefragt, die ITArchivierungsprozesse zur Implementierung der Archivierungs-Geschäftsprozesse über eine Multi-Tier-Information-Lifecycle-Management-Landschaft zu implementieren. Diese könnte die Unternehmens-IT dazu verwenden, auch Produktpartner ihres Unternehmens zu werden. Ein Beispiel dafür könnte wieder die IT unseres Telekommunikationsunternehmens darstellen. Diese beschafft zur Speicherung der Daten der Archivierungsphase des Informationslebenszyklus Tier-3Speicherhardware und -software. Diese ist jedoch auch zu nutzen für ein ClientOnline-Backup, die Datensicherung des Kunden-PC’s, die vom Telekommunikationsunternehmen die DSL-Zugänge zum Internet bereitgestellt bekommen. Client-Online-Backup wird somit zu einem zusätzlichen Produkt des Kerngeschäftes des Telekommunikationsunternehmens, das aus der IT als Produktpartner des Unternehmens in das Kerngeschäft des Unternehmens gegeben wurde. Information Lifecycle Management ist also nicht nur als lästige Aufgabe zu betrachten. Es liefert über TCO-Betrachtungen hinweg der IT jede Menge von Möglichkeiten, sich enger in das Kerngeschäft des jeweiligen Unternehmens einzubinden.

54

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.17. T-Entwicklung und ILM

2.4 Die Informationswert-Aufbewahrungszeit-Matrix Gemäß den von Moore formulierten neuen Ansätzen ist es immer wichtiger zu verstehen, wo Daten während ihres Lebenszyklus idealerweise gespeichert und wie sie verwaltet werden sollten. Er postuliert für die Mehrzahl digitaler Daten die Maxime „90 Tage auf Platte und 90 Jahre auf Magnetband“22 und stellt dabei die These auf, Daten sollten 30 Tage nach ihrer Erstellung auf Tier-1-Speichersystemen, vom 31. bis 90. Tag ihrer Existenz auf Tier-2-Speicher und danach auf Tier-3-Speicher aufbewahrt werden. Diese These wird in Abb. 2.18 durch den Parameter „Wiederherstellungszeitziel“ unterstrichen, die die diametrale Entwicklung von Aufbewahrungszeit und Wiederherstellungszeit dokumentiert. Moore unterstellt in seinem Datenlebenszyklus-Modell zusätzlich, dass der Wert der Information jeweils innerhalb der einzelnen Speicherebenen (Tier 1 bis Tier 3) ansteigt und abfällt, also eine alternierende Folge zwischen ansteigendem und abfallendem Informationswert darstellt. Diese Einschätzung vom Verlauf des Informationswertes durch Moore basiert unter anderem auf der Festlegung seiner 90-Tage-Maxime. Die von Moore postulierte Fixierung auf 90 Tage berücksichtigt nicht die unterschiedlichen Lebenszyklen von Informationen gemäß den unterschiedlichen  22

Moore, Fred: Storage New Horizons, a.a.O., S. 12.

2.4 Die Informationswert-Aufbewahrungszeit-Matrix

55

Abb. 2.18. Das Daten-Lebenszyklus-Modell nach Moore23

Anforderungen aus den Geschäftsprozessen der verschiedenen Branchen. Außerdem sind für ihn die determinierenden Parameter lediglich x x x x

Wiederverwendungswahrscheinlichkeit, Datenmenge, Zeitraum seit Datenerstellung und Wiederherstellungszeitziel.

Wir, beide Autoren, haben auf Basis von konkreten Projekterfahrungen und alternativen TCO-Betrachtungen festgestellt, dass sich jede Information innerhalb eines Zyklus von Erstellungs-, Verdichtungs-, Nutzungs-, Bewahrungs- und Archivierungsphase bewegt, die nicht nach einem festen Theorem hinsichtlich ihrer jeweiligen Dauern gespeichert werden müssen. Weiter haben wir festgestellt, dass die beschreibenden Parameter für die lebenszykluskonformen Strategien im Rahmen des Informationslebenszyklus über den Moore’schen-Ansatz hinaus die Punkte umfassen: x x x x

Betriebszeit, Betriebsnebenzeiten, Physische Wiederherstellzeit, Logische Wiederherstellzeit,

 23

Moore, Fred, Storage New Horizons, a.a.O., S. 12.

56

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.19. Der Wert der Daten, u. a. nach Moore24 und eigene Analysen

x x x x

Maximaler geplanter Datenverlust, Notwendigkeit eines Service-Desks, Reaktionszeit und Notwendigkeit einer Bereitschaft.

Wir haben auch beschrieben, dass Informationen in den späteren Lebenszyklusphasen nur durch Eintreten von Sonderbedingungen nochmals an operativem Wert für das Unternehmen gewinnen (vgl. Abb. 2.7), ansonsten jedoch in den späteren Lebenszyklusphasen (d. h. in der Bewahrungs- und der Archivierungsphase) überproportional an Wert verlieren, so dass sich die Kurve der Wertentwicklung für die Information im Informationslebenszyklus der Wiederverwendungswahrscheinlichkeit annähert (vergleiche Abb. 2.20). Aus diesem Grunde kann man eine Portfolioanalyse für das Informationsmanagement unseres Erachtens als Informationswert-Aufbewahrungszeit-Matrix darstellen, da diese beiden Faktoren klar die IT-Strategien hinsichtlich des Information Lifecycle Management für eine IT als Erfolgspartner des Unternehmens repräsentieren. Die Problem-Children, bezogen auf die gespeicherten Informationen sind Daten in der Erstellungsphase mit hohem Informationswert für das Geschäft des Unternehmens und einer noch nicht klaren Rest-Aufbewahrungszeit (vergleiche Abb. 2.21). Diese Informationen durchlaufen die Verdichtungsphase, wo sie  24

Moore, Fred: Storage New Horizons, a.a.O., S. 12.

2.4 Die Informationswert-Aufbewahrungszeit-Matrix

57

Abb. 2.20. Der Wert der Daten gemäß durchgeführter Analysen

genutzt werden. Daher wird eine Vielzahl der hier erfassten Informationen nur eine kurze Nutzungszeit haben. Hier stimmen wir mit dem Moore’schen Theorem insofern überein, dass innerhalb der ersten Phase, bei Moore bis 30 Lebenstage, bei uns in Abhängigkeit vom Geschäftsprozess (d. h. innerhalb einer Spanne von wenigen Tagen bis Monaten), es sich entscheidet, wie die Information den Lebenszyklus durchläuft. Innerhalb der Verdichtungs- und Nutzungsphase haben die Informationen einen hohen Geschäftswert für das Unternehmen und eine lange Aufbewahrungszeit. Mit der Nutzung der Daten unterliegen diese den Anforderungen an eine eventuell geforderte Langzeitarchivierung. Die Star-Informationen sind Informationen der Verdichtungs- und Nutzungsphase und werden gegen Ende der Nutzungsphase zu den Cash-CowInformationen. Das sind Informationen, die keiner weiteren Änderung mehr unterliegen und damit in der Prozessinfrastruktur keine weiteren Kosten mehr erzeugen, aber für das Tagesgeschäft des Unternehmens weiter genutzt werden können, bis sie in die Bewahrungsphase gelangen. Diese Informationen am Ende der Nutzungsphase und der Bewahrungsphase sinken in ihrem Wert für das Unternehmen, haben jedoch durch die noch anstehende Archivierungsphase eine lange Aufbewahrungszeit. Die Dogs der Informationen sind die Daten gegen Ende der Archivierungsphase mit geringem Wert für das Unternehmen und geringer Aufbewahrungszeit.

58

2 Information Lifecycle und Information Lifecycle Management

Abb. 2.21. Die Informationswert-Aufbewahrungszeit-Matrix

Das Finden des richtigen Informationsportfolios ist Aufgabe des Informationsmanagements. Der richtige IT-Strategien-Mix im Informationslebenszyklus ist der Weg zu diesem Ziel. Die Implementierung des Strategien-Mix, d. h. die richtige Dimensionierung des Zyklus, bestehend aus Erstellungs-, Verdichtungs-, Nutzungs-, Bewahrungs- und Archivierungsphase, im Sinne einer Informationswert-Aufbewahrungszeit-Matrix sowie deren geeignete IT-technische Realisierung, ist die zentrale Aufgabe des Information Lifecycle Management, wie es in den folgenden Kapiteln unter Beachtung aller primären und sekundären Anforderungen beschrieben wird.

3 Rechtliche Grundlagen des Information Lifecycle Management

3.1 Information Lifecycle Management und Compliance Bei unseren ersten beiden Projekten zur Implementierung eines Information Lifecycle Management – das erste bei einem Telekommunikationsunternehmen, das zweite bei einem Energieversorgungsunternehmen – kamen uns nach der ersten Einarbeitung Zweifel, ob die Zieldefinition „Information Lifecycle Management“ mit einigen Daten, die dieses Ziel operational machten, überhaupt die richtige Zielsetzung sei. Sollte eine solches Projekt nicht besser als ComplianceProjekt bezeichnet werden, das sicherstellen soll, die Arbeitnehmerhaftung für Non-Compliance an führender Stelle der betroffenen Unternehmen zu verhindern? Diese Legitimation für Information Lifecycle Management ist erlaubt, jedoch – wie die vorhergehenden Seiten aufzeigen – nicht allein ausreichend. Dennoch ist die Motivation zur Implementierung eines Information Lifecycle Management stark und – bei Betrachtung lebensechter Beispiele bei ENRON und MCI – leicht zu vermitteln. Doch was bedeutet eigentlich Compliance? Nähert man sich diesem Begriff lexikalisch, so kann man mit drei Begriffen ziemlich genau beschreiben, was Compliance bedeuten soll. Die Begriffe sind: x to comply in etwas einwilligen, zustimmen; x to complete etwas durchführen, vervollständigen, vollenden und x Compliance Befolgung. Das „etwas“, in das eingewilligt und dem zugestimmt wird (to comply), als auch das „etwas“, das durchgeführt, vervollständigt und vollendet wird (to complete), sind die Erhebung, Verarbeitung, Archivierung, der Zugriff auf und die Löschung von Daten oder kurz das, was wir im Vorherigen als Information Lifecycle Management definiert und beschrieben haben. Die „Befolgung“, um die es der Compliance geht, ist die Befolgung nationaler und internationaler Rechtsvorschriften bezüglich Erhebung, Verarbeitung, Archivierung, Zugriff auf und Löschung von Daten, die Lokalisierung der betroffenen IT-Prozesse und deren Anpassung, so eine solche notwendig ist. Somit stellt das Erreichen der Compliance nicht nur ein klassisches „Quick-Fix-Projekt“ der IT eines Unternehmens dar, sondern ist vielmehr eine „Lebensart“, ein „ethisches Moment“ innerhalb der Corporate Governance eines Unternehmens.

60

3 Rechtliche Grundlagen des Information Lifecycle Management

In diesem Abschnitt des Buches stellen wir die relevanten nationalen (deutschen), europäischen und internationalen (US-amerikanischen) Rechtsvorschriften dar, deren Befolgung Compliance ausmacht. Außerdem zeigen wir, welche Auswirkungen die Non-Compliance haben kann, um Compliance als Motivator für die Implementierung eines Information Lifecycle Management zusätzlich zur TCO-Betrachtung zu gewinnen und auch um klarzustellen, dass eine um Compliance bemühte IT sich als Erfolgspartner des Unternehmens in dessen ureigenen Unternehmenszielen präsentiert. Als nationale Rechtsvorschriften, die hinsichtlich Compliance relevant sind, betrachten wir: x x x x x x x x x x x x

Bindende Rechtsvorschriften des Handelsgesetzbuches (HGB), Compliance-relevante Vorschriften der Abgabenordnung, Das Umsatzsteuergesetz, Sonstige Regelungen zur ordnungsgemäßen Buchführung, Die Regelungen des Bundesdatenschutzgesetzes, Regelungen des bürgerlichen Gesetzbuches (BGB), Zivilprozessordnung, Sozialgesetzbuch, Die Medizingeräteverordnung von 1986, Die Röntgenverordnung, Das Gesetz zur Modernisierung des Gesundheitssystems, Das Kreditwesengesetz.

Als über das nationale deutsche Recht hinausgehende europäische (Rechts-) Vorschriften betrachten wir: x Die Empfehlungen des Baseler Ausschusses für Bankenaufsicht (Basel II) und x Die Good Manufacturing Practice der EU-Kommission. Die von uns betrachteten internationalen (US-amerikanischen) Rechtsvorschriften sind: x x x x x x x x

Die Information Retention Laws, Die Privacy Laws, Die Food and Drug Administration 21CFR Part 11, Der Health Insurance Portability and Accountability Act (HIPAA), Der Gramm-Leach-Bliley Act, Regelungen der Federal Rules of Civil Procedure, Der Electronic Signatures in Global and National Commerce Act (E-SIGN), Die Control Objectives for Information and related Technology (COBIT) sowie die interne Kontrolle gemäß dem Committee of Sponsoring Organisations of the Treadway Commission (COSO), x Regelungen des Sarbanes-Oxley Act (SOX), x Regularien der US-Börsenaufsicht SEC Rule 17a-4, x Regelungen des Department of Defense (DoD) 5015.2.

3.2 Nationale (deutsche) Rechtsvorschriften

61

Letztendlich untersuchen wir in diesem Buch, welche Zertifizierungen hinsichtlich Compliance von wem und nach welchen internationalen Standards für das IT-Management durchgeführt werden. Dabei betrachten wir folgende Standards: x ISO 15489 Information and Documentation – Records Management und x ISO 17799-1 Information Technology – Code of Practice for Information Security Management. Zielsetzung der detaillierten Beschäftigung mit diesen Rechtsvorschriften ist es, dem Leser Hilfestellung bei folgenden Punkten im Rahmen eines Projektes zur Implementierung des Information Lifecycle Managements zu geben: x Die Anforderungen an seine Umgebung exakt zu definieren. Hier soll er dazu befähigt werden, zu klären, welche konkreten Rechtsvorschriften von ihm erfüllt werden müssen, wer die Kontrollinstanz für die Compliance ist und welche Inhalte und Prozesse geprüft werden. x Eng mit den Kontrollinstanzen zusammenzuarbeiten. Hier soll der Leser ermuntert werden, eine Kommunikationsmatrix für Fachabteilung und Management, internes Controlling und externe Prüfer aufzustellen. x Die Anforderungen den Eigenschaften der von ihm geplanten und zu implementierenden ILM-Umgebung zuzuordnen. Dabei können wir nur Hinweise und Empfehlungen aussprechen. Wir können mit diesem Buch keinen Anspruch auf Vollständigkeit erheben. Dies ist insbesondere nicht möglich, als die gesetzlichen Anforderungen ebenfalls ständigen Änderungen unterliegen und natürlich unsere Interpretation unserem Verständnis dieser Anforderungen entspricht. ILM erfordert ein Verständnis von Kaufleuten, Ingenieuren, Informatikern, Personal-, Geschäftsprozess-Experten, Fachexperten usw. sowie natürlich von den Projektmanagern, das deutlich über das rein juristische Verständnis hinausgeht. Daher sollte der Compliance-Part eines ILM-Projektes stets von dem internen Controlling und der internen Rechtsabteilung begleitet werden, die den aktuellen Bezug zu den ComplianceRechtsvorgaben sicherstellen müssen.

3.2 Nationale (deutsche) Rechtsvorschriften 3.2.1 Bindende Rechtsvorschriften des Handelsgesetzbuches (HGB) Das Handelsgesetzbuch regelt im Wesentlichen die Buchführungspflicht und schreibt vor welche Dokumente wie lange aufbewahrt werden müssen. Die Basis aller nationalen Rechtsvorschriften, deren Compliance gefordert ist, ist die Buchführungspflicht des Kaufmanns, geregelt in HGB § 238.

62

3 Rechtliche Grundlagen des Information Lifecycle Management

Abb. 3.1. HGB § 238 Buchführungspflicht

Abb. 3.2. HGB § 239 Führung der Handelsbücher

3.2 Nationale (deutsche) Rechtsvorschriften

63

§ 257 Aufbewahrung von Unterlagen. Aufbewahrungsfristen (1) Jeder Kaufmann ist verpflichtet, die folgenden Unterlagen geordnet aufzubewahren: 1.Handelsbücher, Inventare, Eröffnungsbilanzen, Jahresabschlüsse, Einzelabschlüsse nach § 325 Abs. 2a, Lageberichte, Konzernabschlüsse, Konzernlageberichte sowie die zu ihrem Verständnis erforderlichen Arbeitsanweisungen und sonstigen Organisationsunterlagen, 2. die empfangenen Handelsbriefe, 3. Wiedergaben der abgesandten Handelsbriefe, 4. Belege für Buchungen in den von ihm nach § 238 Abs. 1 zu führenden Büchern. (2) Handelsbriefe sind nur Schriftstücke, die ein Handelsgeschäft betreffen. (3) Mit Ausnahme der Eröffnungsbilanzen und Abschlüsse können die in Absatz 1 aufgeführten Unterlagen auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsmäßiger Buchführung entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten 1. mit den empfangenen Handelsbriefen und den Buchungsbelegen bildlich und mit den anderen Unterlagen inhaltlich übereinstimmen, wenn sie lesbar gemacht werden, 2. während der Dauer der Aufbewahrungsfrist verfügbar sind und jederzeit innerhalb angemessener Frist lesbar gemacht werden können. Sind Unterlagen auf Grund des § 239 Abs. 4 Satz 1 auf Datenträgern hergestellt worden, können statt des Datenträgers die Daten auch ausgedruckt aufbewahrt werden; die ausgedruckten Unterlagen können auch nach Satz 1 aufbewahrt werden. (4) Die in Absatz 1 Nr. 1 und 4 aufgeführten Unterlagen sind zehn Jahre, die sonstigen in Absatz 1 aufgeführten Unterlagen sechs Jahre aufzubewahren. (5) Die Aufbewahrungsfrist beginnt mit dem Schluss des Kalenderjahrs, in dem die letzte Eintragung in das Handelsbuch gemacht, das Inventar aufgestellt, die Eröffnungsbilanz oder der Jahresabschluss festgestellt, der Einzelabschluss nach § 325 Abs. 2a oder der Konzernabschluss aufgestellt, der Handelsbrief empfangen oder abgesandt worden oder der Buchungsbeleg entstanden ist. Abb. 3.3. HGB § 257 Aufbewahrung der Unterlagen45

§ 238 HGB fordert in Absatz 1 die Nachvollziehbarkeit der Geschäftsvorfälle hinsichtlich Entstehung und Abwicklung und regelt in Absatz 2 die Pflicht des Kaufmanns zur dokumentenechten Aufbewahrung der Dokumente zum Geschäftsvorfall. Letzteres wird in Absatz 3 HGB § 239 Führung der Handelsbücher präzisiert. Absatz 4 regelt die Formen und Verfahren der Buchführung gemäß den Grundzügen ordentlicher Buchführung (vgl. hinten), Verfügbarkeit der Daten innerhalb der Aufbewahrungsfrist sowie die Forderung der Lesbarkeit der Daten innerhalb angemessener Frist. Diese Formulierung dokumentiert, dass die während der Aufbewahrungsfrist archivierten Dokumente und Daten nicht sofort (online) oder zeitnah (nearline) aufbewahrt werden müssen, sondern mit einer angemessenen Frist zur Wiedergewinnung versehen sind. 

45

Fassung aufgrund des Gesetzes zur Einführung internationaler Rechnungslegungsstandards und zur Sicherung der Qualität der Abschlussprüfung (Bilanzrechtsreformgesetz – BilReG) vom 4.12.2004 m.W.v. 10.12.2004.

64

3 Rechtliche Grundlagen des Information Lifecycle Management

HGB § 257 definiert die Unterlagen, die aufbewahrt werden müssen, sowie deren Aufbewahrungsfristen. Demnach müssen folgende Dokumente für zehn Jahre aufbewahrt werden: x x x x x x x x

Handelsbücher, Inventare, Eröffnungsbilanzen, Jahresabschlüsse, Einzelabschlüsse nach HGB § 325 Abs. 2a, Lageberichte, Konzernabschlüsse, Konzernlageberichte sowie die zu ihrem Verständnis erforderlichen Arbeitsanweisungen und sonstigen Organisationsunterlagen, x Belege für Buchungen in den nach HGB § 238 Abs. 1 zu führenden Büchern. Sechs Jahre aufbewahrt werden müssen die empfangenen Handelsbriefe und die Wiedergaben der abgesandten Handelsbriefe.

3.2.2 Compliance-relevante Vorschriften der Abgabenordnung (AO) Die Abgabenordnung regelt in § 147 die Anforderungen an den Kaufmann aus dem HGB aus steuerlicher Sicht. Interessant erscheint hier Absatz 1 Satz 5, der die aufbewahrungspflichtigen Dokumente nach HGB erweitert um „sonstige Unterlagen, soweit sie für die Besteuerung von Bedeutung sind“. Dabei beinhalten diese sonstigen Unterlagen sämtliche Dokumente über Ereignisse, die die Kosten und den Umsatz des Unternehmens tangieren, also praktisch alles, was an geschäftsrelevanten Daten und Informationen erzeugt, oder empfangen und versendet wird. Insbesondere enthalten sind Dokumente zur Fakturierung, Materialwirtschaft, Zeiterfassung, Reisekostenabrechnung, Kosten- und Leistungsrechnung, Investitionsrechnung (darunter auch banale Tabellenkalkulationen sowie Vereinbarungen zu Terminen, Zahlungen, Rabatten und Preisen. Hiermit gehören auch alle elektronischen Mails, die solche Informationen enthalten oder sich auf solche Informationen beziehen, zu diesen aufbewahrungspflichtigen sonstigen Unterlagen. Dies erzwingt definitiv eine E-Mail-Policy für die geschäftliche Nutzung der elektronischen Post und eine E-Mail-Archivierung. § 147 Absatz 2 regelt die Speichermedien, mit Hilfe derer der Aufbewahrungspflicht Genüge geleistet werden soll. „Mit Ausnahme der Jahresabschlüsse und der Eröffnungsbilanz können die Unterlagen auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden (…).“ Diese werden in dem Anwendungserlass zur Abgabenordnung wie folgt präzisiert. Auch der Anwendungserlass lässt die technische Entwicklung bei den in Frage kommenden Datenträgern offen. Satz 3 beschreibt lediglich Beispiele. Bei der Auswahl eines technischen

3.2 Nationale (deutsche) Rechtsvorschriften

65

Datenträgers sollte auf jeden Fall eine Zertifizierung des technischen Systems zur Compliance vorgelegt werden, damit den Anforderungen von HGB und AO Genüge geleistet wird.

§ 147 Ordnungsvorschriften für die Aufbewahrung von Unterlagen (1) Die folgenden Unterlagen sind geordnet aufzubewahren: 1. Bücher und Aufzeichnungen, Inventare, Jahresabschlüsse, Lageberichte, die Eröffnungsbilanz sowie die zu ihrem Verständnis erforderlichen Arbeitsanweisungen und sonstigen Organisationsunterlagen, 2. die empfangenen Handels- oder Geschäftsbriefe, 3. Wiedergaben der abgesandten Handels- oder Geschäftsbriefe, 4. Buchungsbelege, 4a. Unterlagen, die einer mit Mitteln der Datenverarbeitung abgegebenen Zollanmeldung nach Artikel 77 Abs. 1 in Verbindung mit Artikel 62 Abs. 2 Zollkodex beizufügen sind, sofern die Zollbehörden nach Artikel 77 Abs. 2 Satz 1 Zollkodex auf ihre Vorlage verzichtet oder sie nach erfolgter Vorlage zurückgegeben haben. 5. sonstige Unterlagen, soweit sie für die Besteuerung von Bedeutung sind. (2) Mit Ausnahme der Jahresabschlüsse, der Eröffnungsbilanz und der Unterlagen nach Absatz 1 Nr. 4 a können die in Absatz 1 aufgeführten Unterlagen auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsmäßiger Buchführung entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten 1. mit den empfangenen Handels- oder Geschäftsbriefen und den Buchungsbelegen bildlich und mit den anderen Unterlagen inhaltlich übereinstimmen, wenn sie lesbar gemacht werden, 2. während der Dauer der Aufbewahrungsfrist verfügbar sind, unverzüglich lesbar gemacht und maschinell ausgewertet werden können. (3) Die in Absatz 1 Nr. 1, 4 und 4 a aufgeführten Unterlagen sind zehn Jahre, die sonstigen in Absatz 1 aufgeführten Unterlagen sechs Jahre aufzubewahren, sofern nicht in anderen Steuergesetzen kürzere Aufbewahrungsfristen zugelassen sind. Kürzere Aufbewahrungsfristen nach außersteuerlichen Gesetzen lassen die in Satz 1 bestimmte Frist unberührt. Die Aufbewahrungsfrist läuft jedoch nicht ab, soweit und solange die Unterlagen für Steuern von Bedeutung sind, für welche die Festsetzungsfrist noch nicht abgelaufen ist; § 169 Abs. 2 Satz 2 gilt nicht. (4) Die Aufbewahrungsfrist beginnt mit dem Schluss des Kalenderjahrs, in dem die letzte Eintragung in das Buch gemacht, das Inventar, die Eröffnungsbilanz, der Jahresabschluss oder der Lagebericht aufgestellt, der Handels- oder Geschäftsbrief empfangen oder abgesandt worden oder der Buchungsbeleg entstanden ist, ferner die Aufzeichnung vorgenommen worden ist oder die sonstigen Unterlagen entstanden sind. Abb. 3.4. Abgabenordnung § 147  Ordnungsvorschriften für die Aufbewahrung von Unterlagen (Teil 1)46

 46

Aus BGBl I 1976, 613 (1977, 269).

66

3 Rechtliche Grundlagen des Information Lifecycle Management

Noch § 147 Ordnungsvorschriften für die Aufbewahrung von Unterlagen (5) Wer aufzubewahrende Unterlagen in der Form einer Wiedergabe auf einem Bildträger oder auf anderen Datenträgern vorlegt, ist verpflichtet, auf seine Kosten diejenigen Hilfsmittel zur Verfügung zu stellen, die erforderlich sind, um die Unterlagen lesbar zu machen; auf Verlangen der Finanzbehörde hat er auf seine Kosten die Unterlagen unverzüglich ganz oder teilweise auszudrucken oder ohne Hilfsmittel lesbare Reproduktionen beizubringen. (6) Sind die Unterlagen nach Absatz 1 mit Hilfe eines Datenverarbeitungssystems erstellt worden, hat die Finanzbehörde im Rahmen einer Außenprüfung das Recht, Einsicht in die gespeicherten Daten zu nehmen und das Datenverarbeitungssystem zur Prüfung dieser Unterlagen zu nutzen. Sie kann im Rahmen einer Außenprüfung auch verlangen, dass die Daten nach ihren Vorgaben maschinell ausgewertet oder ihr die gespeicherten Unterlagen und Aufzeichnungen auf einem maschinell verwertbaren Datenträger zur Verfügung gestellt werden. Die Kosten trägt der Steuerpflichtige. Abb. 3.5. § 147  Ordnungsvorschriften für die Aufbewahrung von Unterlagen (Teil 2)47

Zu § 147  Ordnungsvorschriften für die Aufbewahrung von Unterlagen: 1. Die Aufbewahrungspflicht ist Bestandteil der Buchführungs- und Aufzeichnungspflicht. Wegen der Rechtsfolgen bei Verstößen vgl. zu § 146, Nr. 1. 2. Den in § 147 Abs. 1 Nr. 1 aufgeführten Arbeitsanweisungen und sonstigen Organisationsunterlagen kommt bei DV-gestützten Buchführungen besondere Bedeutung zu. Die Dokumentation hat nach Maßgabe der Grundsätze ordnungsmäßiger DVgestützter Buchführungssysteme  GoBS  (BMF-Schreiben vom 7. November 1995, BStBl I S. 738) zu erfolgen. 3. Bildträger i. S. des § 147 Abs. 2 sind z. B. Fotokopien, Mikrofilme. Als andere Datenträger kommen z. B. Magnetbänder, Magnetplatten, Disketten in Betracht. § 147 Abs. 2 enthält auch die Rechtsgrundlage für das sog. COM-Verfahren (Computer Output Microfilm); bei diesem Verfahren werden die Daten aus dem Computer direkt auf Mikrofilm ausgegeben. Bei der Aufzeichnung von Schriftgut auf Mikrofilm sind die Mikrofilm-Grundsätze (BMF-Schreiben vom 01.02.1984, BStBl I S. 155) zu beachten. Die Lesbarmachung von in nicht lesbarer Form aufbewahrten Unterlagen richtet sich nach § 147 Abs. 5. Abb. 3.6. Anwendungserlass zur Abgabenordnung (AEAO)48

3.2.3 Ergänzungen des Umsatzsteuergesetzes (UStG) § 14 UStG – Ausstellung von Rechnungen definiert die Rechnung als eines der „sonstigen Dokumente“ gemäß AO § 147, Absatz 1, Satz 5. Die Bestimmungen aus UStG § 14 Absatz 3 Satz 1 beinhalten bei der Verarbeitung und Archivierung  47 48

Aus BGBl I 1976, 613 (1977, 269). BMF-Schreiben vom 15. Juli 1998 BStBL I S. 630, geändert durch BMF-Schreiben vom 14. Februar 2000 (BStBl. I S. 190), vom 27. September 2000 (BStBl. I S. 1232) und vom 22. Dezember 2000 (BStBl. I S. 1549:2).

3.2 Nationale (deutsche) Rechtsvorschriften

67

§ 14 Ausstellung von Rechnungen (1) Rechnung ist jedes Dokument, mit dem über eine Lieferung oder sonstige Leistung abgerechnet wird, gleichgültig, wie dieses Dokument im Geschäftsverkehr bezeichnet wird. Rechnungen sind auf Papier oder vorbehaltlich der Zustimmung des Empfängers auf elektronischem Weg zu übermitteln. (…) (3) Bei einer auf elektronischem Weg übermittelten Rechnung müssen die Echtheit der Herkunft und die Unversehrtheit des Inhalts gewährleistet sein durch 1. eine qualifizierte elektronische Signatur oder eine qualifizierte elektronische Signatur mit Anbieter-Akkreditierung nach dem Signaturgesetz vom 16. Mai 2001 (BGBl. I S. 876), das durch Artikel 2 des Gesetzes vom 16. Mai 2001 (BGBl. I S. 876) geändert worden ist, in der jeweils geltenden Fassung, oder 2. elektronischen Datenaustausch (EDI) nach Artikel 2 der Empfehlung 94/820/EG der Kommission vom 19. Oktober 1994 über die rechtlichen Aspekte des elektronischen Datenaustausches (ABl. EG Nr. L 338 S. 98), wenn in der Vereinbarung über diesen Datenaustausch der Einsatz von Verfahren vorgesehen ist, die die Echtheit der Herkunft und die Unversehrtheit der Daten gewährleisten, und zusätzlich eine zusammenfassende Rechnung auf Papier oder unter den Voraussetzungen der Nummer 1 auf elektronischem Weg übermittelt wird. (…) Abb. 3.7. § 14 UStG – hier Ausstellung von Rechnungen49

elektronisch übermittelter und signierter Rechnungen die Prüfung der Signatur, die Protokollierung der Prüfung, die Aufbewahrung der Signaturschlüssel und eine anschließende Speicherung auf einem Datenträger, der eine nachträgliche Änderung nicht mehr zulässt.

3.2.4 Sonstige Regelungen 3.2.4.1 Grundsätze ordnungsgemäßer Buchführung Die Grundsätze ordnungsgemäßer Buchführung (GoB) stellen einen normativen Begriff, kein Dokument oder Gesetzeswerk dar. Sie dienen zur Beschreibung der Ziele der Rechnungslegung und der geübten Praxis ehrbarer Kaufleute. Gesetzestechnisch stellen die Grundsätze ordnungsgemäßer Buchführung einen unbestimmten Rechtsbegriff dar. Sie setzen dort ein, wo der Gesetzgeber keine gesetzliche Regelung vorgegeben hat. Die „Kaufmannschaft“ hat im Laufe der letzten Jahrhunderte eine Reihe von Vorstellungen darüber entwickelt, in welcher Weise ordentliche Kaufleute die Geschäftsvorfälle des Betriebes aufzeichnen und im Jahresabschluss darstellen. Diese Vorstellungen fanden als Handelsusancen und Handelssitten zunehmend Berücksichtigung in der Rechtsprechung […]. Die Gesamtheit der teils kodifizierten, teils auch nur nach kaufmännischen Gepflogenheiten eingehaltenen  49

Fassung der Bekanntmachung vom 9. Juni 1999 (BGBl. I S. 1270).

68

3 Rechtliche Grundlagen des Information Lifecycle Management

R 29. Ordnungsmäßige Buchführung; Allgemeines (1) 1 Bei der Gewinnermittlung nach § 5 EStG sind  soweit sich aus den Steuergesetzen nichts anderes ergibt  die handelsrechtlichen Rechnungslegungsvorschriften sowie die Vorschriften der §§ 140 bis 148, 154 AO zu beachten. 2 Handelsrechtliche Rechnungslegungsvorschriften im Sinne des Satzes 1 sind die Vorschriften des Ersten Abschnitts, für Kapitalgesellschaften außerdem die des Zweiten Abschnitts des Dritten Buchs des HGB. 3 Entsprechen die Buchführung und die Aufzeichnungen des Steuerpflichtigen diesen Vorschriften, so sind sie der Besteuerung zugrunde zu legen, soweit nach den Umständen des Einzelfalles kein Anlass ist, ihre sachliche Richtigkeit zu beanstanden. Handelsrechtliche Grundsätze ordnungsmäßiger Buchführung (2) 1 Eine Buchführung ist ordnungsmäßig, wenn die für die kaufmännische Buchführung erforderlichen Bücher geführt werden, die Bücher förmlich in Ordnung sind und der Inhalt sachlich richtig ist (BFH vom 25. 3. 1954 BStBl III S. 195). 2 Der Jahresabschluss muss "innerhalb der einem ordnungsmäßigen Geschäftsgang entsprechenden Zeit" (§ 243 Abs. 3 HGB) aufgestellt werden (BFH vom 6. 12. 1983 BStBl 1984 II S. 227); bei Kapitalgesellschaften gilt § 264 Abs. 1 HGB. 3 Bei Aufstellung der Bilanz sind alle diejenigen wertaufhellenden Umstände zu berücksichtigen, die für die Verhältnisse am Bilanzstichtag von Bedeutung sind. 4 Ein bestimmtes Buchführungssystem ist nicht vorgeschrieben; allerdings muss bei Kaufleuten, soweit sie nicht Minderkaufleute im Sinne des § 4 HGB sind, die Buchführung den Grundsätzen der doppelten Buchführung entsprechen (§ 242 Abs. 3 HGB). 5 Im Übrigen muss die Buchführung so beschaffen sein, dass sie einem sachverständigen Dritten innerhalb angemessener Zeit einen Überblick über die Geschäftsvorfälle und über die Vermögenslage des Unternehmens vermitteln kann. 6 Die Geschäftsvorfälle müssen sich in ihrer Entstehung und Abwicklung verfolgen lassen (§ 238 Abs. 1 HGB; auch BFH vom 18. 2. 1966  BStBl III S. 496 und vom 23. 9. 1966  BStBl 1967 III S. 23). … Abb. 3.8. GoB gemäß EStR 1993, R 29 (Teil 1 und Teil 2)50

Grundsätze zur Buchführung und Bilanzierung werden zusammenfassend als Grundsätze ordnungsgemäßer Buchführung und Bilanzierung oder auch einfach nur als Grundsätze ordnungsgemäßer Buchführung bezeichnet. Entscheidend beeinflusst werden die Grundsätze ordnungsmäßiger Bilanzierung von den Gedanken der Rechenschaftslegung und des Gläubigerschutzes. Diese finden ihren Niederschlag in den Vorschriften und geforderten Prinzipien über die materielle und formelle Ordnungsmäßigkeit der Bilanzierung. Bei den Vorschriften und Prinzipien zur materiellen Ordnungsmäßigkeit handelt es sich in erster Linie um die Bewertungsgrundsätze, die Vorstellungen von Rechtsprechung und Praxis zur  50

Aus: Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994).

3.2 Nationale (deutsche) Rechtsvorschriften

69

Ordnungsmäßige Eintragung in den Geschäftsbüchern (3) 1 Die Eintragungen in den Geschäftsbüchern und die sonst erforderlichen Aufzeichnungen müssen vollständig, richtig, zeitgerecht und geordnet vorgenommen werden (§ 239 Abs. 2 HGB). 2 Die zeitgerechte Erfassung der Geschäftsvorfälle erfordert Zahlungsverkehrs keine tägliche Aufzeichnung.

mit Ausnahme des baren

3 Es muss jedoch ein zeitlicher Zusammenhang zwischen den Vorgängen und ihrer buchmäßigen Erfassung bestehen (BFH vom 25. 3. 1992  BStBl II S. 1010). 4 Werden bei der Erstellung der Buchführung die Geschäftsvorfälle nicht laufend, sondern nur periodenweise gebucht, ist es nicht zu beanstanden, wenn die grundbuchmäßige Erfassung der Kreditgeschäfte eines Monats bis zum Ablauf des folgenden Monats erfolgt, sofern durch organisatorische Vorkehrungen sichergestellt ist, dass Buchführungsunterlagen bis zu ihrer grundbuchmäßigen Erfassung nicht verloren gehen, z.B. durch laufende Nummerierung der eingehenden und ausgehenden Rechnungen oder durch ihre Abheftung in besonderen Mappen oder Ordnern; die allgemeinen Anforderungen an die Ordnungsmäßigkeit der Buchführung nach Absatz 2 müssen auch in diesem Fall erfüllt sein. 5 Die Funktion der Grundbuchaufzeichnungen kann auf Dauer auch durch eine geordnete und übersichtliche Belegablage erfüllt werden (§ 239 Abs. 4 HGB; § 146 Abs. 5 AO). 6 Einzelhändler brauchen die Kasseneinnahmen in der Regel nicht einzeln aufzuzeichnen (BFH vom12. 5. 1966  BStBl III S. 371). Abb. 3.9. GoB gemäß EStR 1993, R 29 (Teil 3)51

Frage des Bilanzierungsrechtes und der Bilanzierungspflicht sowie den Grundsatz, dass sich der Kaufmann bei der Bilanzierung in Zweifelsfällen von der Vorsicht leiten lassen solle. Innerhalb der Vorschriften und Prinzipien zur formellen Ordnungsmäßigkeit stehen das Prinzip der Bilanzklarheit sowie Rechtsvorschriften im Vordergrund, die die Art und Weise der Aufzeichnungen und ihrer Belege, die Länge der Rechnungsperioden und Ähnliches regeln. Zu ihnen gehören ferner die bekannten Grundsätze der Bilanzidentität (Gleichheit von Schlussbilanz einer Periode und Eröffnungsbilanz der folgenden Periode) und der formellen Bilanzkontinuität (Beibehalten der Grundsätze der Gliederung, der Abgrenzung der einzelnen Positionen und Ähnliches).“52 Die wichtigsten Grundsätze ordnungsgemäßer Buchführung sind in Richtlinie 29 der Einkommenssteuerrichtlinien 1993 dargestellt. Die Einkommensteuerrichtlinien sind Weisungen an die Finanzbehörden zur einheitlichen Anwendung des Einkommensteuerrechts, zur Vermeidung unbilliger Härten und zur Verwaltungsvereinfachung. Die von Diederich genannten grundsätzlichen Ursachen der Einführung der GoB í Gläubigerschutz und Rechenschaftslegung í sind dank der neuerlichen Ereignisse wie ENRON- und MCI-Konkurs wieder ins Blickfeld gerückt und daher heute gültiger denn je.  51 52

Aus: Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994). Diederich, Helmut: Allgemeine Betriebswirtschaftslehre II, a.a.O., S. 204 f.

70

3 Rechtliche Grundlagen des Information Lifecycle Management

Die in der R 29 Absatz 6 (Mängel und Ordnungsmäßigkeit der Buchführung) Satz 4 erwähnte R 12 Absatz 2 Satz 2 besagt, dass bei bestehender Buchführungspflicht und nicht oder nicht ordnungsgemäßer Buchführung das Einkommen gemäß § 5 EstG unter Berücksichtigung des Einzelfalls und gegebenenfalls unter Heranziehung von Richtsätzen geschätzt wird.

Ordnungsmäßige Buchführung bei Kreditgeschäften (4) 1 Bei Kreditgeschäften sind die Entstehung der Forderungen und Schulden und ihre Tilgung grundsätzlich als getrennte Geschäftsvorfälle zu behandeln. 2 Bei einer doppelten Buchführung ist für Kreditgeschäfte in der Regel ein Kontokorrentkonto (BFH vom 18. 2. 1966  BStBl III S. 496), unterteilt nach Schuldnern und Gläubigern, zu führen. 3 Es ist jedoch nicht zu beanstanden, wenn Waren- und Kostenrechnungen, die innerhalb von acht Tagen nach Rechnungseingang oder innerhalb der ihrem gewöhnlichen Durchlauf durch den Betrieb entsprechenden Zeit beglichen werden, kontokorrentmäßig nicht erfasst werden. Kontokorrentbuch (5) 1 Neben der Erfassung der Kreditgeschäfte in einem Grundbuch müssen die unbaren Geschäftsvorfälle, aufgegliedert nach Geschäftsfreunden, kontenmäßig dargestellt werden. 2 Dies kann durch Führung besonderer Personenkonten oder durch eine geordnete Ablage der nicht ausgeglichenen Rechnungen (Offene-Posten-Buchhaltung) erfüllt werden. 3 Ist die Zahl der Kreditgeschäfte verhältnismäßig gering, so gelten hinsichtlich ihrer Erfassung die folgenden Erleichterungen: a) Besteht kein laufender unbarer Geschäftsverkehr mit Geschäftsfreunden, so müssen für jeden Bilanzstichtag über die an diesem Stichtag bestehenden Forderungen und Schulden Personenübersichten aufgestellt werden (BFH vom 23. 2. 1951  BStBl III S. 75). b) 1 Einzelhändler und Handwerker können Krediteinkäufe und Kreditverkäufe kleineren Umfangs vereinfacht buchen. 2 Es genügt, wenn sie die Wareneinkäufe auf Kredit im Wareneingangsbuch in einer besonderen Spalte als Kreditgeschäfte kennzeichnen und den Tag der Begleichung der Rechnung vermerken. 3 Bei Kreditverkäufen ist es insoweit ausreichend, wenn sie einschließlich der Zahlung in einer Kladde festgehalten werden, die als Teil der Buchführung aufzubewahren ist. 4 Außerdem müssen in beiden Fällen für jeden Bilanzstichtag Personenübersichten aufgestellt werden. Abb. 3.10. GoB gemäß EStR 1993, R 29 (Teil 4)53

 53

Aus: Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994).

3.2 Nationale (deutsche) Rechtsvorschriften

71

Mängel und Ordnungsmäßigkeit der Buchführung (6) 1 Enthält die Buchführung formelle Mängel, so ist ihre Ordnungsmäßigkeit nicht zu beanstanden, wenn die Voraussetzungen des Absatzes 2 erfüllt sind, das sachliche Ergebnis der Buchführung nicht beeinflusst wird und die Mängel keinen erheblichen Verstoß gegen die Anforderungen der Absätze 3 bis 5, 7 und 8 bedeuten. 2 Enthält die Buchführung materielle Mängel, z. B. Geschäftsvorfälle sind nicht oder falsch gebucht, so wird ihre Ordnungsmäßigkeit dadurch nicht berührt, wenn es sich dabei um unwesentliche Mängel handelt, z. B. nur unbedeutende Vorgänge sind nicht oder falsch dargestellt. 3 Die Fehler sind dann zu berichtigen oder das Buchführungsergebnis ist durch eine Zuschätzung richtig zu stellen. 4 Bei schwerwiegenden materiellen Mängeln gilt R 12 Abs. 2 Satz 2. Aufbewahrungsfristen (7) 1 Nach § 147 AO sind Bücher und Aufzeichnungen, Inventare, Jahresabschlüsse, Lageberichte, die Eröffnungsbilanz sowie die zu ihrem Verständnis erforderlichen Arbeitsanweisungen und sonstigen Organisationsunterlagen grundsätzlich zehn Jahre, Handels- oder Geschäftsbriefe, Buchungsbelege oder sonstige Unterlagen, soweit sie für die Besteuerung von Bedeutung sind, grundsätzlich sechs Jahre aufzubewahren, sofern nicht in anderen Steuergesetzen kürzere Aufbewahrungsfristen zugelassen sind. 2 Die Aufbewahrungsfrist läuft jedoch nicht ab, soweit und solange die Unterlagen für Steuern von Bedeutung sind, für welche die allgemeine Festsetzungsfrist (§ 169 Abs. 2 Satz 1 AO) noch nicht abgelaufen ist (§ 147 Abs. 3 Satz 2 AO). 3 Haben Rechnungen usw. Buchfunktion, z. B. bei der Offene-Posten-Buchhaltung, so sind sie so lange wie Bücher aufzubewahren. 4 Eine Aufbewahrung der Registrierkassenstreifen, Kassenzettel, Bons und dergleichen ist im Einzelfall nicht erforderlich, wenn der Zweck der Aufbewahrung in anderer Weise gesichert und die Gewähr der Vollständigkeit der von Registrierkassenstreifen usw. übertragenen Aufzeichnungen nach den tatsächlichen Verhältnissen gegeben ist (BFH vom 12. 5. 1966  BStBl III S. 371). 5 Diese Voraussetzungen sind hinsichtlich der Registrierkassenstreifen regelmäßig erfüllt, wenn Tagesendsummenbons aufbewahrt werden, die die Gewähr der Vollständigkeit bieten und die folgenden Angaben enthalten: Name des Geschäfts, Datum und Tagesendsumme. Abb. 3.11. GoB gemäß EStR 1993, R 29 (Teil 5)54

R 29 definiert also in den Absätzen 1 bis 5 die wesentlichen Grundsätze ordnungsgemäßer Buchführung und wie deren sachlich methodisch gerechte Umsetzung auszusehen hat. Absatz 6 regelt, wann eine Buchführung nicht ordnungsgemäß ist und definiert in Verbindung mit R 12 Absatz 2 Satz 2 die Folgen der nicht Ordnungsmäßigkeit. Absatz 7 erläutert die für den Informationslebenszyklus relevanten Aufbewahrungsfristen, während Absatz 8 die Datenträger definiert, mit denen den Aufbewahrungsfristen Genüge getan wird.

 54

Aus: Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994).

72

3 Rechtliche Grundlagen des Information Lifecycle Management

Buchführung auf Datenträgern (8) 1 Die Bücher und die sonst erforderlichen Aufzeichnungen können auch auf Datenträgern, z. B. Magnetplatten, Magnetbändern, Disketten, geführt werden, soweit diese Formen der Buchführung einschließlich des dabei angewandten Verfahrens den Grundsätzen ordnungsmäßiger Buchführung entsprechen (§ 146 Abs. 5 AO). 2 Bei einer Buchung auf Datenträgern müssen die Daten jederzeit innerhalb angemessener Frist lesbar gemacht werden können (Ausdruckbereitschaft). 3 Auf Verlangen der Finanzbehörde, z. B. anlässlich einer Außenprüfung, ist unverzüglich ganz oder teilweise auszudrucken (§ 147 Abs. 5 AO). 4 Die Ordnungsmäßigkeit einer Buchführung auf Datenträgern richtet sich grundsätzlich nach den gleichen Vorschriften und Grundsätzen, die auch für die anderen Buchführungsformen maßgebend sind; die Absätze 1 bis 7 gelten daher entsprechend. 5 Die maßgebenden handelsrechtlichen Grundsätze ordnungsmäßiger Buchführung sind durch die "Grundsätze ordnungsmäßiger Speicherbuchführung  GoS " (BMF vom 5. 7. 1978  BStBl I S. 250) ergänzt worden, denen insbesondere hinsichtlich der allgemeinen Anforderungen an die Dokumentation und Prüfbarkeit eine grundsätzliche Bedeutung für jede Buchführung auf Datenträgern zukommt. 6 Unter den Voraussetzungen des § 147 Abs. 2 AO können mit Ausnahme der Eröffnungsbilanz und des Jahresabschlusses die in Absatz 7 Satz 1 aufgeführten Unterlagen auch als Wiedergabe auf einem Bildträger, z. B. Fotokopie, Mikrokopie, oder auf anderen Datenträgern aufbewahrt werden. 7 Die Vorschrift enthält auch die Rechtsgrundlage für das sog. COM-Verfahren (Computer Output Microfilm), bei dem magnetgespeicherte Daten direkt auf Mikrofilm übertragen werden. 8 Als "andere Datenträger" kommen insbesondere die maschinell lesbaren Datenträger, z. B. Magnetband, Magnetplatte, Diskette, in Betracht. 9 Die bei Buchführung auf Datenträgern anfallenden Datenträger sind entsprechend ihrer Funktion im Rechnungswerk (Grundbuch, Konto, Beleg) den in § 147 Abs. 1 AO aufgeführten Arten von Unterlagen zuzuordnen und demgemäß aufzubewahren. Abb. 3.12. GoB gemäß EStR 1993, R 29 (Teil 6)55

3.2.4.2 Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS) Mit den Grundsätzen ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS)56 werden die allgemeinen Grundsätze ordnungsgemäßer Buchführung als Maßstab für die Ordnungsmäßigkeit der Buchführung für den Bereich DVgestützter Buchführung präzisiert. Sie gelten nicht allein für eine konventionelle Speicherbuchführung, die einfach ein elektronisches Abbild einer manuellen Buchführung darstellt, sondern u. a. auch für Dokumentenmanagementsysteme.57 Tz. 2 beschreibt, wie zur Gewährleistung der retrograden und progressiven Prüfung die Beleg-, Journal- und Kontenfunktionen eines DV-gestützten Buch 55 56

57

Aus: Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994). Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 – IV A 8 – S 0316 – 52/95 – BStBl 1995 I, S. 738. Vgl. GoBS Tz. 1, Abschnitt c) aus Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

73

V. Datensicherheit (Tz. 5 der GoBS) Zu sichern und zu schützen sind neben den genannten "Informationen" auch die Änderungen der Tabellen- und Stammdaten. Ihre Sicherung ist ebenso von Bedeutung wie die Sicherung anderer Programm- und Stammdaten. Der Schutz der sensiblen Informationen des Unternehmens auch gegen unberechtigte Kenntnisnahme bezieht sich nicht auf die Vorlage von Unterlagen im Rahmen einer Außenprüfung. Ziel der Datensicherungsmaßnahmen ist es, die Risiken für die gesicherten Programme/Datenbestände hinsichtlich Unauffindbarkeit, Vernichtung und Diebstahl zu vermeiden. Systematische Verzeichnisse über die gesicherten Programme/Datenbestände sollen das Risiko der Unauffindbarkeit ausschließen. Das Risiko der Vernichtung der Datenträger ist durch geeignete Aufbewahrungsorte zu vermeiden. Abb. 3.13. Datensicherheit  Tz. 5 der GoBS58

führungssystems auszusehen haben. Tz. 3 legt die Unveränderbarkeit einmal getätigter Buchungen fest. Tz. 4 beschreibt das interne Kontrollsystem (IKS) des DV-gestützten Buchführungssystems, das als ein wichtiges Kriterium für die Ordnungsmäßigkeit gilt. Dieses wird als die „Gesamtheit aller aufeinander abgestimmten und miteinander verbundenen Kontrollen, Maßnahmen und Regelungen bezeichnet, die die folgenden Aufgaben haben:

Vl. Dokumentation und Prüfbarkeit (Tz. 6 der GoBS) a) Für jedes DV-gestützte Buchführungssystem ist eine Dokumentation zu erstellen (Verfahrensdokumentation).Tz. 6.2 der GoBS zeigt Bereiche auf, auf die sich die Verfahrensdokumentation "insbesondere" erstrecken muss. Es handelt sich nicht um eine abschließende Aufzählung aller aufbewahrungspflichtigen Dokumentationsunterlagen, sondern lediglich um einen Rahmen für den Umfang der Dokumentation. Der Umfang der im Einzelfall erforderlichen Dokumentation wird dadurch bestimmt, was zum Verständnis der Buchführung notwendig ist. b) Bestandteil der Verfahrensdokumentation ist auch eine Beschreibung der vom Programm zugelassenen Änderungen von Systemeinstellungen durch den Anwender. Die Beschreibung der variablen, benutzerdefinierten Aufgabenstellungen ist Teil der sachlogischen Beschreibung. c) Die Beschreibung der programmtechnischen Lösung beinhaltet auch die Gültigkeitsdauer einer Tabelle. Zum Nachweis der Programmidentität ist das sog. Programmprotokoll (Umwandlungsliste, Übersetzungsliste) erforderlich. Als Teil der Verfahrensdokumentation stellt dieses Protokoll regelmäßig den einzigen genauen Nachweis über den Inhalt des tatsächlich verwendeten Programms dar (§ 147 Abs. 1 Nr. 1 AO). Abb. 3.14. Dokumentation und Prüfbarkeit  Tz. 6 der GoBS59

 58 59

Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O. Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O.

74

3 Rechtliche Grundlagen des Information Lifecycle Management

VII. Aufbewahrungsfristen (Tz. 7 der GoBS) Die in Tz. 7 der GoBS genannten Aufbewahrungsfristen können sich gemäß § 147 Abs. 3 Satz 2 AO verlängern. Zur Anwendung dieser Bestimmung ist eine Verwaltungsregelung ergangen (Bundessteuerblatt 1977 Teil I S. 487). Abb. 3.15. Aufbewahrungsfristen, Tz. 7 der GoBS61

x Sicherung und Schutz des vorhandenen Vermögens und vorhandener Informationen vor Verlusten aller Art; x Bereitstellung vollständiger, genauer und aussagefähiger sowie zeitnaher Aufzeichnungen; x Förderung der betrieblichen Effizienz durch Auswertung und Kontrolle der Aufzeichnungen und x Unterstützung der Befolgung der vorgeschriebenen Geschäftspolitik.“60 Tz. 5 regelt die Datensicherheit, Tz. 6 die Dokumentation und Prüfbarkeit, Tz. 7 die Aufbewahrungsfristen sowie Tz. 8 der GoBS die Wiedergabe der Unterlagen. VIII. Wiedergabe der auf Datenträgern geführten Unterlagen (Tz. 8 der GoBS) a) Der Buchführungspflichtige, der aufzubewahrende Unterlagen nur in Form einer Wiedergabe auf einem Datenträger vorlegen kann, ist verpflichtet, auf seine Kosten diejenigen Hilfsmittel zur Verfügung zu stellen, die erforderlich sind, um die Unterlagen lesbar zu machen; auf Verlangen der Finanzbehörde hat er auf seine Kosten die Unterlagen unverzüglich ganz oder teilweise auszudrucken bzw. lesbare Reproduktionen beizubringen b) § 147 Abs. 2 AO schreibt zur Archivierung von Unterlagen (Dokumenten) auf digitalen Datenträgern keine besondere Technik vor. Die Regelung ist bewusst so gefasst worden, dass sie keine bestimmte Technologie vorschreibt. Mit Ausnahme der Jahresabschlüsse und der Eröffnungsbilanz ist damit die Speicherung/Archivierung der aufbewahrungspflichtigen Unterlagen (Dokumente) auf digitalen Datenträgern als sog. "andere Datenträger" i. S. d. § 147 Abs. 2 AO zulässig. Dabei sind grundsätzlich zwei Verfahren zu unterscheiden: 1. Speicherung von analogen Dokumenten (in Papierform verkörperte Dokumente) Analoge Dokumente werden im Anschluss an den Scannvorgang auf digitalen Datenträgern archiviert. Der Scannvorgang bedarf einer genauen Organisationsanweisung darüber,  wer scannen darf  zu welchem Zeitpunkt gescannt wird  welches Schriftgut gescannt wird  ob eine bildliche oder inhaltliche Übereinstimmung mit dem Original erforderlich ist (§ 147 Abs. 1 Nr. 2 oder 3 AO)  wie die Qualitätskontrolle auf Lesbarkeit und Vollständigkeit und  wie die Protokollierung von Fehlern zu erfolgen hat. Das mittels Scannen entstandene digitale Dokument ist mit einem unveränderbaren Index zu versehen. Hard- und softwaremäßig muss sichergestellt sein, dass das Scannergebnis unveränderbar ist. Im Anschluss an den Scannvorgang darf die weitere Bearbeitung nur mit dem gespeicherten Beleg erfolgen. Abb. 3.16. Wiedergabe der Daten − Tz. 8 GoBS (Teil 1)62

 60 61

Anlage zum BMF-Schreiben vom 7. November 1995 IV A 8 – S 0316 – 52/95. Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

75

2. Speicherung von originär digitalen Dokumenten Originär digitale Dokumente werden durch Übertragung der Inhalts- und Formatierungsdaten auf einen digitalen Datenträger archiviert. Bei originär digitalen Dokumenten muss hard- und softwaremäßig sichergestellt sein, dass während des Übertragungsvorgangs auf das Speichermedium eine Bearbeitung nicht möglich ist. Die Indexierung hat wie bei gescannten Dokumenten zu erfolgen. Das so archivierte digitale Dokument kann nur unter dem zugeteilten Index bearbeitet und verwaltet werden. Die Bearbeitungsvorgänge sind zu protokollieren und mit dem Dokument zu speichern. Das bearbeitete Dokument ist als "Kopie" zu kennzeichnen. Die gespeicherten Dokumente müssen während der gesamten Aufbewahrungsfrist jederzeit reproduzierbar, d. h. lesbar sein (vgl. zu VII.). c) Bei der Speicherung auf Datenträgern ist bei bestimmten Unterlagen sicherzustellen, dass die Wiedergabe mit der Originalunterlage bildlich übereinstimmt (§ 147 Abs. 2 Nr. 1 AO). Eine vollständige Farbwiedergabe ist erforderlich, wenn der Farbe Beweisfunktion zukommt. Der Verzicht auf einen herkömmlichen Beleg darf die Möglichkeit der Prüfung des betreffenden Buchungsvorgangs in formeller und sachlicher Hinsicht nicht beeinträchtigen. Der Erhalt der Verknüpfung zwischen Index, digitalem Dokument und Datenträger muss während der gesamten Aufbewahrungsfrist gewährleistet sein. Die Originalunterlagen können darüber hinaus nur vernichtet werden, soweit sie nicht nach anderen Rechtsvorschriften im Original aufzubewahren sind. Abb. 3.17. Wiedergabe der auf Datenträgern geführten Unterlagen − Tz. 8 der GoBS (Teil 2)63

3.2.4.3 Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) Die GDPdU räumen der Finanzbehörde das Recht ein, „die mit Hilfe eines Datenverarbeitungssystems erstellte Buchführung des Steuerpflichtigen durch Datenzugriff zu prüfen. (…) Das Recht auf Datenzugriff steht der Finanzbehörde nur im Rahmen steuerlicher Außenprüfungen zu. (…) Gegenstand der Prüfung sind wie bisher nur die nach § 147 Absatz 1 AO aufbewahrungspflichtigen Unterlagen.“64 Dabei kann die Finanzbehörde drei Möglichkeiten zum Datenzugriff auf steuerlich relevante elektronische Daten nutzen: x Den unmittelbaren Lesezugriff, x den mittelbaren Zugriff über Auswertungen und x die Datenüberlassung in verschiedenen Formaten. Abschnitt II der GDPdU definiert die Prüfbarkeit digitaler Unterlagen. So muss bei elektronischen Abrechnungen im Sinne des § 14 Absatz 4 Satz 2 UStG (Vorsteuerabzug aus elektronischen Abrechnungen mit qualifizierter elektronischer Signatur und Anbieter-Akkreditierung) über die GoBS hinaus: 62 63 64

Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O. Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7. November 1995 a.a.O. Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (DGPdU), Schreiben des BMF an die obersten Finanzbehörden der Länder vom 16. Juli 2001 – IV D 2 – S 0316 – 136/01.

76

3 Rechtliche Grundlagen des Information Lifecycle Management

x Die elektronische Signatur hinsichtlich Integrität und Berechtigung geprüft und die Prüfung protokolliert werden. x Der Signaturprüfschlüssel aufbewahrt werden. x Die Speicherung der elektronischen Abrechnung auf einem nicht mehr zu ändernden Datenträger erfolgen oder sichergestellt werden, dass die elektronische Änderung nach Speicherung nicht mehr geändert werden kann. x Eine in ein Inhouse-Format konvertierte elektronische Abrechnung gemeinsam mit ihrem Original sowie beide Dokumente mit dem gleichen Index gemäß GoBS archiviert und die konvertierte Version als solche kenntlich gemacht werden. x Bei verschlüsselten Abrechnungen die verschlüsselte und unverschlüsselte Abrechnung sowie der Kryptografieschlüssel aufbewahrt werden. x Der Eingang, die Archivierung, die Konvertierung (falls erfolgt) sowie die Verarbeitung der elektronischen Abrechnung protokolliert werden. x Sichergestellt werden, dass die Übertragungs-, Archivierungs- und Konvertierungssysteme den Anforderungen der GoBS (Verfahrensdokumentation, internes Kontrollsystem IKS, Sicherungskonzept und Aufbewahrung) entsprechen. x Das qualifizierte Zertifikat des Empfängers aufbewahrt wird.

2. Sonstige aufbewahrungspflichtige Unterlagen Bei sonstigen aufbewahrungspflichtigen Unterlagen i.S.d. § 147 Abs. 1 AO, die digitalisiert sind und nicht in Papierform übermittelt werden, muss das dabei angewendete Verfahren den GoBS entsprechen. Der Originalzustand der übermittelten ggf. noch verschlüsselten Daten muss erkennbar sein (§ 146 Abs. 4 AO). Die Speicherung hat auf einem Datenträger zu erfolgen, der Änderungen nicht mehr zulässt. Bei einer temporären Speicherung auf einem änderbaren Datenträger muss das Datenverarbeitungssystem sicherstellen, dass Änderungen nicht möglich sind. Bei Einsatz von Kryptographietechniken sind die verschlüsselte und die entschlüsselte Unterlage aufzubewahren. Bei Umwandlung (Konvertierung) der sonstigen aufbewahrungspflichtigen Unterlagen in ein unternehmenseigenes Format (sog. Inhouse-Format) sind beide Versionen zu archivieren und nach den GoBS mit demselben Index zu verwalten sowie die konvertierte Version als solche zu kennzeichnen. Wenn Signaturprüfschlüssel oder kryptographische Verfahren verwendet werden, sind die verwendeten Schlüssel aufzubewahren. Bei sonstigen aufbewahrungspflichtigen Unterlagen sind der Eingang, ihre Archivierung und ggf. Konvertierung sowie die weitere Verarbeitung zu protokollieren. Abb. 3.18. Prüfbarkeit sonstiger aufbewahrungspflichtiger Unterlagen nach GDPdU 65

 65

Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (DGPdU), Schreiben des BMF an die obersten Finanzbehörden der Länder vom 16. Juli 2001, a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

77

Die Prüfbarkeit der sonstigen aufbewahrungspflichtigen Unterlagen entspricht der der elektronischen Abrechnungen. Die Archivierung der digitalen Unterlagen ist in Absatz III geregelt. Die GDPdU haben zunächst relativ wenig Interesse gefunden und wurden lediglich in steuerlichen Fachzirkeln diskutiert. Die strikte Anwendung der GDPdU durch die Finanzbehörden, die Umsetzung in die Prüfungssoftware IDEA und die Managementverantwortung für die Korrektheit der Buchführung und der archivierten Daten haben jedoch für eine intensive Auseinandersetzung und Implementierung gesorgt.66

III. Archivierung digitaler Unterlagen Originär digitale Unterlagen nach § 146 Abs. 5 AO sind auf maschinell verwertbaren Datenträgern zu archivieren. Originär digitale Unterlagen sind die in das Datenverarbeitungssystem in elektronischer Form eingehenden und die im Datenverarbeitungssystem erzeugten Daten; ein maschinell verwertbarer Datenträger ist ein maschinell lesbarer und auswertbarer Datenträger. Die originär digitalen Unterlagen dürfen nicht ausschließlich in ausgedruckter Form oder auf Mikrofilm aufbewahrt werden. Somit reicht die Aufzeichnung im COM-Verfahren (Computer-Output-Microfilm) nicht mehr aus. Diese Einschränkung gilt nicht, wenn die vor der Übertragung auf Mikrofilm vorhandenen Daten vorgehalten werden, die eine maschinelle Auswertbarkeit durch das Datenverarbeitungssystem gewährleisten. Nicht ausreichend ist auch die ausschließliche Archivierung in maschinell nicht auswertbaren Formaten (z.B. pdf-Datei). Eine Pflicht zur Archivierung einer Unterlage i.S. des § 147 Abs. 1 AO in maschinell auswertbarer Form (§ 147 Abs. 2 Nr. 2 AO) besteht nicht, wenn diese Unterlage zwar DV-gestützt erstellt wurde, sie aber nicht zur Weiterverarbeitung in einem DVgestützten Buchführungssystem geeignet ist (z.B. Textdokumente). Originär in Papierform angefallene Unterlagen, z.B. Eingangsrechnungen, können weiterhin mikroverfilmt werden. Kann im Falle eines abweichenden Wirtschaftsjahrs die Archivierung ab 1. Januar 2002 nachweisbar aus technischen Gründen nicht auf einem maschinell auswertbaren Datenträger (§ 147 Abs. 2 Nr. 2 AO) erfolgen, wird dies nicht beanstandet, wenn der Steuerpflichtige bis spätestens zu Beginn des anschließenden abweichenden Wirtschaftsjahrs den Archivierungspflichten gemäß § 147 Abs. 2 Nr. 2 AO nachkommt. Abb. 3.19. Archivierung digitaler Unterlagen nach GDPdU67

 66

67

Vgl. auch: Fragen und Antworten zum Datenzugriffsrecht der Finanzverwaltung, http://www.bundesfinanzministerium.de/DE/Service/Downloads/Abt__IV/ 009,property=publicationFile,cap.locale=de.pdf; Vgl. auch: Information zum „Beschreibungsstandard für die Datenüberlassung“, http://www.bundesfinanzministerium.de/DE/Service/Downloads/Abt__IV/ 010,property=publicationFile,cap.locale=de.pdf; Vgl. auch: Graf von Kerssenbrock, Otto-Ferdinand, Riedel, Olaf, Zöllkau, York Steuerliches Risikomanagement/Tax Risk Management. Am Beispiel des Datenzugriffs der Finanzverwaltung nach § 147 Abs. 6 AO und GDPdU– Schreiben, 1. Auflage, Bonn, 2005. Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (DGPdU), Schreiben des BMF an die obersten Finanzbehörden der Länder vom 16. Juli 2001, a.a.O.

78

3 Rechtliche Grundlagen des Information Lifecycle Management

3.2.4.4 Die Regelungen des Bundesdatenschutzgesetzes Das Bundesdatenschutzgesetz definiert Anforderungen im Hinblick auf Datenschutz, Datensicherheit und Auswertbarkeit personenbezogener Daten. Demnach sind personenbezogene Daten sämtliche Informationen, die direkt mit § 3a Datenvermeidung und Datensparsamkeit Gestaltung und Auswahl von Datenverarbeitungssystemen haben sich an dem Ziel auszurichten, keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen. Insbesondere ist von den Möglichkeiten der Anonymisierung und Pseudoanonymisierung Gebrauch zu machen, soweit dies möglich ist und der Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht. Abb. 3.20. Datenvermeidung und Datensparsamkeit68 § 20 Berichtigung, Löschung und Sperrung von Daten (1) personenbezogene Daten sind zu berichtigen, wenn sie unrichtig sind. Wird festgestellt, dass personenbezogene Daten in Akten unrichtig sind, oder wird ihre Richtigkeit von dem Betroffenen bestritten, so ist dies in der Akte zu vermerken oder auf sonstige Weise festzuhalten. (2) personenbezogene Daten in Dateien sind zu löschen, wenn 1. ihre Speicherung unzulässig ist oder 2. ihre Kenntnis für die speichernde Stelle zur Erfüllung der in ihrer Zuständigkeit liegenden Aufgaben nicht mehr erforderlich ist. (3) An die Stelle einer Löschung tritt eine Sperrung, soweit 1. einer Löschung gesetzliche, satzungsmäßige oder vertragliche Aufbewahrungsfristen entgegenstehen, 2. Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des Betroffenen beeinträchtigt würden, oder 3. eine Löschung wegen der besonderen Art der Speicherung nicht oder nur mit unverhältnismäßig hohem Aufwand möglich ist. (4) personenbezogene Daten in Dateien sind ferner zu sperren, soweit ihre Richtigkeit vom Betroffenen bestritten wird und sich weder die Richtigkeit noch die Unrichtigkeit feststellen lässt. (5) personenbezogene Daten in Akten sind zu sperren, wenn die Behörde im Einzelfall feststellt, dass ohne die Sperrung schutzwürdige Interessen des Betroffenen beeinträchtigt würden und die Daten für die Aufgabenerfüllung der Behörde nicht mehr erforderlich sind. (…) Abb. 3.21. § 20 BDSG Berichtigung, Löschung und Sperrung von Daten69

 68

69

Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I S. 66), geändert durch § 13 Absatz 1 des Gesetzes vom 5. September 2005 (BGBl. I S. 2722). Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003, a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

79

natürlichen Personen verknüpft sind oder verknüpft werden können. § 3 BDSG definiert personenbezogene Daten sowie weitere Begriffsbestimmungen im Umfeld der Erhebung von Daten mit Personenbezug. Dabei sind Gestaltung und Auswahl von Datenverarbeitungssystemen vom Grundsatz der Datenvermeidung und Datensparsamkeit des § 3a BDSG geprägt. Aus diesem erwächst ebenfalls, dass personenbezogene Daten, nachdem entsprechend der Rechtsgrundlage für ihre Erhebung die Frist für die Speicherung abgelaufen ist, sofort gelöscht werden müssen. An die Stelle der Löschung tritt eine Sperrung, wenn eine Löschung wegen der besonderen Art der Speicherung nicht oder nur mit unverhältnismäßig hohem Aufwand möglich ist.

3.2.4.5 Regelungen des bürgerlichen Gesetzbuches (BGB) Das BGB beschreibt die Unterschriftenregelung in § 126. Ist durch ein Gesetz schriftliche Form vorgeschrieben, so muss eine Urkunde von dem Aussteller eigenhändig durch Namensunterschrift oder mittels notariell beglaubigtem Handzeichen unterzeichnet sein. Im Formanpassungsgesetz wird dies ergänzt: „Die Schriftform kann durch die Textform mit qualifizierter digitaler Signatur ersetzt werden.“70 § 298 SGB III Behandlung von Daten (1) Vermittler dürfen Daten über zu besetzende Ausbildungs- und Arbeitsplätze und über Ausbildung Suchende und Arbeitnehmer nur erheben, verarbeiten und nutzen, soweit dies für die Verrichtung ihrer Vermittlungstätigkeit erforderlich ist. Sind diese Daten personenbezogen oder Geschäfts- oder Betriebsgeheimnisse, dürfen sie nur erhoben, verarbeitet oder genutzt werden, soweit der Betroffene im Einzelfall nach Maßgabe des § 4a des Bundesdatenschutzgesetzes eingewilligt hat. Übermittelt der Vermittler diese Daten im Rahmen seiner Vermittlungstätigkeit einer weiteren Person oder Einrichtung, darf diese sie nur zu dem Zweck verarbeiten oder nutzen, zu dem sie ihr befugt übermittelt worden sind. (2) Vom Betroffenen zur Verfügung gestellte Unterlagen sind unmittelbar nach Abschluss der Vermittlungstätigkeit zurückzugeben. Die übrigen Geschäftsunterlagen des Vermittlers sind nach Abschluss der Vermittlungstätigkeit drei Jahre aufzubewahren. Die Verwendung der Geschäftsunterlagen ist zur Kontrolle des Vermittlers durch die zuständigen Behörden sowie zur Wahrnehmung berechtigter Interessen des Vermittlers zulässig. Personenbezogene Daten sind nach Ablauf der Aufbewahrungspflicht zu löschen. Der Betroffene kann nach Abschluss der Vermittlungstätigkeit Abweichungen von den Sätzen 1, 3 und 4 gestatten; die Gestattung bedarf der Schriftform. Abb. 3.22. Behandlung von Daten nach SGB III71

 70

71

Gesetz zur Anpassung der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen Rechtsgeschäftsverkehr, Bundesgesetzblatt Jahrgang 2001 Teil I Nr. 35, ausgegeben zu Bonn am 18. Juli 2001. Sozialgesetzbuch, Drittes Buch (III) – Arbeitsförderung [Artikel 1 des ArbeitsförderungsReformgesetzes - AFRG] vom 24. März 1997 (BGBl. I 1997 S. 594) zuletzt geändert durch Artikel 1 des Gesetzes zur ganzjährigen Beschäftigung vom 24. April 2006 (BGBl. I 2006 Nr. 19 S. 926).

80

3 Rechtliche Grundlagen des Information Lifecycle Management

3.2.4.6 Zivilprozessordnung Auf die Urkunde als Beweismittel zielt die Zivilprozessordnung. Aus dem herkömmlichen Rechtsverständnis definiert eine Urkunde ein Originaldokument in Papierform. Sie muss folgende Anforderungen erfüllen: Integrität: Jede nachträgliche Veränderung des Inhalts ist erkennbar. Authentizität: Die Unterschrift des Ausstellers ist vorhanden. Ein Dokument, das diese Eigenschaften nicht besitzt, unterliegt als Objekt des Augenscheins gemäß den §§ 286 II und 371 ff. der Zivilprozessordnung der freien Beweiswürdigung durch den Richter.

3.2.4.7 Sozialgesetzbuch (SGB) Das Sozialgesetzbuch definiert die Bestimmungen des Bundesdatenschutzgesetzes hinsichtlich der Datenhaltung, Weitergabe und Aufbewahrung für seinen Geltungsbereich. So wird in § 298 SGB III die Behandlung der Daten bei der Vermittlung durch die Bundesagentur für Arbeit geregelt.72 So regelt Absatz 1, dass personenbezogene Daten, Betriebs- und Geschäftsgeheimnisse nur nach individueller Zustimmung des Betroffenen gemäß § 4a BDSG erhoben, verarbeitet, verwendet und aufbewahrt werden dürfen und nur zweckgebunden zur Vermittlung verwendet werden dürfen. Absatz 2 regelt die dreijährige Aufbewahrungspflicht nach Abschluss der Vermittlungstätigkeit. Das vierte Sozialgesetzbuch enthält die gemeinsamen Vorschriften an die Sozialversicherungen in Deutschland. Träger der Sozialversicherung im engeren Sinne sind nicht staatliche Behörden selbst, sondern öffentliche oder halböffentliche Sozialversicherer. Die Sozialversicherung ist meist in Sparten gegliedert, in Deutschland gehören zur Sozialversicherung: x x x x x

Die gesetzliche Rentenversicherung (RV), Die gesetzliche Krankenversicherung (GKV), Die Arbeitslosenversicherung bei der Bundesagentur für Arbeit (BA), Die Unfallversicherung (UV), Die Pflegeversicherung (PV).

Für diese Träger der Sozialversicherung fixiert § 110a SGB IV die Aufbewahrungspflichten von erhobenen Daten. Die Regelungen zur Aufbewahrungspflicht spiegeln die Regelungen aus der Abgabenordnung und den GoBS wider. Sie verpflichten die Träger zur Sozialversicherung zu Lebenszyklus-konformer Archivierung von Daten. Diese wird durch § 110 b SGB IV verstärkt, der die Rückgabe, Vernichtung und Archivierung von Unterlagen durch den Sozialversicherungsträger festlegt.  72

Vgl. Sozialgesetzbuch, Drittes Buch (III) í Arbeitsförderung a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

81

§ 110a Aufbewahrungspflicht (1) Die Behörde bewahrt Unterlagen, die für ihre öffentlich-rechtliche Verwaltungstätigkeit, insbesondere für die Durchführung eines Verwaltungsverfahrens oder für die Feststellung einer Leistung, erforderlich sind, nach den Grundsätzen ordnungsmäßiger Aufbewahrung auf. (2) Die Behörde kann an Stelle der schriftlichen Unterlagen diese als Wiedergabe auf einem Bildträger oder auf anderen dauerhaften Datenträgern aufbewahren, soweit dies unter Beachtung der Grundsätze der Wirtschaftlichkeit und Sparsamkeit den Grundsätzen ordnungsmäßiger Aufbewahrung entspricht. Nach den Grundsätzen ordnungsmäßiger Aufbewahrung von auf Datenträgern aufbewahrten Unterlagen ist insbesondere sicherzustellen, dass die Wiedergabe auf einem Bildträger oder die Daten auf einem anderen dauerhaften Datenträger; a) mit der diesen zugrunde gelegten schriftlichen Unterlage bildlich und inhaltlich vollständig übereinstimmen, wenn sie lesbar gemacht werden, und über diese Übereinstimmung ein Nachweis geführt wird; b) während der Dauer der Aufbewahrungsfrist jederzeit verfügbar sind und unverzüglich bildlich und inhaltlich unverändert lesbar gemacht werden können, die Ausdrucke oder sonstigen Reproduktionen mit der schriftlichen Unterlage bildlich und inhaltlich übereinstimmen und als Unterlage für die Herstellung der Wiedergabe nur dann der Abdruck einer Unterlage verwendet werden darf, wenn die dem Abdruck zugrunde liegende Unterlage bei der Behörde nicht mehr vorhanden ist. Die Sätze 1 und 2 gelten auch für die Aufbewahrung von Unterlagen, die nur mit Hilfe einer Datenverarbeitungsanlage erstellt worden sind, mit der Maßgabe, dass eine bildliche Übereinstimmung der Wiedergabe auf dem dauerhaften Datenträger mit der erstmals erstellten Unterlage nicht sichergestellt sein muss. (3) Können aufzubewahrende Unterlagen nur in der Form einer Wiedergabe auf einem Bildträger oder als Daten auf anderen dauerhaften Datenträgern vorgelegt werden, sind, soweit die Akteneinsicht zu gestatten ist, bei der Behörde auf ihre Kosten diejenigen Hilfsmittel zur Verfügung zu stellen, die erforderlich sind, die Unterlagen lesbar zu machen. Soweit erforderlich, ist die Behörde verpflichtet, die Unterlagen ganz oder teilweise auszudrucken oder ohne Hilfsmittel lesbare Reproduktionen beizubringen; die Behörde kann Ersatz ihrer Aufwendungen in angemessenem Umfang verlangen. (4) Absatz 2 gilt nicht für Unterlagen, die als Wiedergabe auf einem Bildträger aufbewahrt werden, wenn diese Wiedergabe vor dem 1. Februar 2003 erfolgt Abb. 3.23. Aufbewahrungspflicht nach § 110 a SGB IV (Teil 1 und Teil 2)73

 73

Sozialgesetzbuch (SGB) Viertes Buch (IV); Gemeinsame Vorschriften für die Sozialversicherung, (Artikel I des Gesetzes vom 23. Dezember 1976, BGBl. I S. 3845) in der Fassung vom 23. Januar 2006 (BGBl. I S. 86 (466)), zuletzt geändert durch Artikel 8 des Gesetzes vom 29. Juni 2006 (BGBl. I S. 1402).

82

3 Rechtliche Grundlagen des Information Lifecycle Management

§ 110b Rückgabe, Vernichtung und Archivierung von Unterlagen (1) Unterlagen, die für eine öffentlich-rechtliche Verwaltungstätigkeit einer Behörde nicht mehr erforderlich sind, können nach den Absätzen 2 und 3 zurückgegeben oder vernichtet werden. Die Anbietungs- und Übergabepflichten nach den Vorschriften des Bundesarchivgesetzes und der entsprechenden gesetzlichen Vorschriften der Länder bleiben unberührt. Satz 1 gilt insbesondere für 1. Unterlagen, deren Aufbewahrungsfristen abgelaufen sind, 2. Unterlagen, die nach Maßgabe des § 110a Abs. 2 als Wiedergabe auf einem maschinell verwertbaren dauerhaften Datenträger aufbewahrt werden und 3. der Behörde vom Betroffenen oder von Dritten zur Verfügung gestellte Unterlagen. (2) Unterlagen, die einem Träger der gesetzlichen Rentenversicherung von Versicherten, Antragstellern oder von anderen Stellen zur Verfügung gestellt worden sind, sind diesen zurückzugeben, soweit sie nicht als Ablichtung oder Abschrift dem Träger auf Anforderung von den genannten Stellen zur Verfügung gestellt worden sind; werden die Unterlagen anderen Stellen zur Verfügung gestellt, sind sie von diesen Stellen auf Anforderung zurückzugeben. (3) Die übrigen Unterlagen im Sinne von Absatz 1 werden vernichtet, soweit kein Grund zu der Annahme besteht, dass durch die Vernichtung schutzwürdige Interessen des Betroffenen beeinträchtigt werden. Abb. 3.24. Rückgabe, Vernichtung und Archivierung nach § 110b SGB IV74

3.2.4.8 Die Medizingeräteverordnung Die Medizingeräteverordnung hat zunächst scheinbar geringe Auswirkung auf das in diesem Buch behandelte Thema. Dennoch soll auf einige Anforderungen aus der Medizingeräteverordnung von 1986 hingewiesen werden, die das Thema am Rande streifen. Die Medizingeräteverordnung von 1986 findet ihre Anwendung auf Betreiber medizinisch-technischer Geräte in Deutschland. Daten sind hier bedingt für die Erstellungs-, Verdichtungs-, Nutzungs- und Bewahrungsphase im Informationslebenszyklus betroffen. Speichersysteme für die Speicherung der Daten sind von der Medizingeräteverordnung möglicherweise betroffen, wenn sie direkt zum Betrieb des Medizingerätes benötigt werden. Dies trifft beispielsweise auf Computer- und Magnetresonanztomographen zu. Die Anwendung medizinisch-technischer Geräte muss sicher sein. Dies bedeutet im Einzelnen: x Der Betreiber muss dafür Sorge tragen, dass die Geräte in funktionsfähigem Zustand erhalten und notwendige Wartungs- und Instandsetzungsarbeiten unverzüglich vorgenommen werden. x Der Arzt muss dafür Sorge tragen, dass das Gerät entsprechend seiner Funktionsweise sachgerecht zum Einsatz kommt.  74

Sozialgesetzbuch (SGB) Viertes Buch (IV) í Gemeinsame Vorschriften für die Sozialversicherung, a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

83

x Das Bedienungspersonal muss die nötigen Kenntnisse haben, das Gerät zu betreiben und die Funktionsfähigkeit zu prüfen. x Das Wartungspersonal muss neben der Behebung von Defekten auch vorbeugend den Zustand des Gerätes überprüfen.

3.2.4.9 Röntgenverordnung

75

Die Verordnung zur Änderung der Röntgenverordnung vom 30. April 2003 dient der Umsetzung der Richtlinie 96/29/EURATOM des Rates vom 13. Mai 1996 zur Festlegung der grundlegenden Sicherheitsnormen für den Schutz der Gesundheit der Arbeitskräfte und der Bevölkerung gegen die Gefahren durch ionisierende Strahlungen (ABI. EG Nr. L 159 S. 1) und der Richtlinie 97/43/EURATOM des Rates vom 30. Juni 1997 über den Gesundheitsschutz von Personen gegen die Gefahren ionisierender Strahlung bei medizinischer Exposition und zur Aufhebung der Richtlinie 84/466/EURATOM (ABI. EG Nr. L 180 S. 22). Die Röntgenverordnung (RöV) regelt in § 28 die Aufzeichnungspflichten. Nach Absatz 1 müssen bei jeder Röntgenuntersuchung folgende Daten aufgezeichnet werden: x Die Ergebnisse der Patientenbefragung, die nach RöV § 23 Absatz 2, Satz 2 und Absatz 3, Satz 1 zuvor stattgefunden haben muss, x Zeitpunkt und Art der Anwendung, x Körperregion, x Angaben zur rechtfertigenden Indikation nach RöV § 23 Absatz 1 Satz 1, x Bei einer Untersuchung zusätzlich den erhobenen Befund, x Falls erfasst die Strahlenexposition des Patienten oder die Informationen zur Ermittlung der Strahlenexposition, x Bei einer Behandlung zusätzlich den Bestrahlungsplan nach RöV § 27 Absatz 1 Satz 1 und das Bestrahlungsprotokoll nach RöV § 27 Absatz 3. Die Aufzeichnungen sind gegen unbefugten Zugriff und unbefugte Änderung zu schützen. Gemäß Absatz 3 sind Aufzeichnungen über Röntgenbehandlungen 30 Jahre lang nach der letzten Behandlung aufzubewahren. Die Röntgenbilder (4) Röntgenbilder und die Aufzeichnungen nach Absatz 1 Satz 2 können als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn sichergestellt ist, dass die Wiedergaben oder die Daten mit den Bildern oder Aufzeichnungen bildlich oder inhaltlich übereinstimmen, wenn sie lesbar gemacht werden, während der Dauer der Aufbewahrungsfrist verfügbar sind und jederzeit innerhalb angemessener Zeit lesbar gemacht werden können, und sichergestellt ist, dass während der Aufbewahrungszeit keine Informationsänderungen oder -verluste eintreten können. Abb. 3.25. Datenträger gemäß Röntgenverordnung76

 75

Verordnung über den Schutz vor Schäden durch Röntgenstrahlung (Röntgenverordnung – RöV) vom 30. April 2003.

84

3 Rechtliche Grundlagen des Information Lifecycle Management

selbst und die Aufzeichnungen nach Absatz 1 Satz 2 über Röntgenuntersuchungen sind zehn Jahre lang nach der letzten Untersuchung aufzubewahren. Absatz 4 beschreibt die Anforderungen an die zur Aufbewahrung gemäß Absatz 3 eingesetzten Datenträger.

3.2.4.10 Das Gesetz zur Modernisierung des Gesundheitssystems Der Gesetzentwurf des Gesetzes zur Modernisierung des Gesundheitssystems (GMG) von 2003 hat Eingang in die Änderungen des SGB V gefunden. Im GMG wurden die Regelungen zur elektronischen Patientenakte geklärt. Ziel des Gesetzes zur Modernisierung des Gesundheitssystems ist die Verbesserung der Qualität und Wirtschaftlichkeit der gesetzlichen Krankenversicherung. Dieses Ziel soll erreicht werden durch: x Die Vermeidung von Doppeluntersuchungen und x die schnelle und korrekte Kommunikation zwischen Hausarzt, Facharzt und Krankenhaus.

SGB V § 68 Finanzierung einer persönlichen elektronischen Gesundheitsakte Zur Verbesserung der Qualität und der Wirtschaftlichkeit der Versorgung können die Krankenkassen ihren Versicherten zu von Dritten angebotenen Dienstleistungen der elektronischen Speicherung und Übermittlung patientenbezogener Gesundheitsdaten finanzielle Unterstützung gewähren. Das Nähere ist durch die Satzung zu regeln. Abb. 3.26. Die elektronische Patientenakte gemäß SGB V77

SGB V § 67 Elektronische Kommunikation (1) Zur Verbesserung der Qualität und Wirtschaftlichkeit der Versorgung soll die papiergebundene Kommunikation unter den Leistungserbringern so bald und so umfassend wie möglich durch die elektronische und maschinell verwertbare Übermittlung von Befunden, Diagnosen, Therapieempfehlungen und Behandlungsberichten, die sich auch für eine einrichtungsübergreifende fallbezogene Zusammenarbeit eignet, ersetzt werden. (2) Die Krankenkassen und Leistungserbringer sowie ihre Verbände sollen den Übergang zur elektronischen Kommunikation nach Absatz 1 finanziell unterstützen. Abb. 3.27. Die elektronische Kommunikation gemäß SGB V78

76

77

78

Verordnung über den Schutz vor Schäden durch Röntgenstrahlung (Röntgenverordnung í RöV), a.a.O. Sozialgesetzbuch (SGB) Fünftes Buch (V) – Gesetzliche Krankenversicherung – Artikel 1 des Gesetzes v. 20. Dezember 1988, BGBl. I S. 2477), zuletzt geändert durch Art. 10 G v. 29. 6..2006 I 1402. Sozialgesetzbuch (SGB) Fünftes Buch (V) – Gesetzliche Krankenversicherung – a.a.O.

3.2 Nationale (deutsche) Rechtsvorschriften

85

SGB V § 285 schränkt die Erfassung und Verwendung personenbezogener Daten über Ärzte, Psychotherapeuten und Zahnärzte durch die Kassenärztlichen und Kassenzahnärztlichen Vereinigungen ein. An Datenschutz und Datensicherheit besondere sind Anforderungen gestellt. Demnach ist der Patient Eigentümer seiner Daten. Außerdem ist die Vergabe und Weitergabe von Zugriffsrechten an behandelnde Institutionen geregelt.

SGB V § 291a Elektronische Gesundheitskarte (5) Das Erheben, Verarbeiten und Nutzen von Daten mittels der elektronischen Gesundheitskarte in den Fällen des Absatzes 3 Satz 1 ist nur mit dem Einverständnis der Versicherten zulässig. Durch technische Vorkehrungen ist zu gewährleisten, dass in den Fällen des Absatzes 3 Satz 1 Nr. 2 bis 6 der Zugriff nur durch Autorisierung der Versicherten möglich ist. Der Zugriff auf Daten sowohl nach Absatz 2 Satz 1 Nr. 1 als auch nach Absatz 3 Satz 1 mittels der elektronischen Gesundheitskarte darf nur in Verbindung mit einem elektronischen Heilberufsausweis, im Falle des Absatzes 2 Satz 1 Nr. 1 auch in Verbindung mit einem entsprechenden Berufsausweis, erfolgen, die jeweils über eine Möglichkeit zur sicheren Authentifizierung und über eine qualifizierte elektronische Signatur verfügen; im Falle des Absatzes 3 Satz 1 Nr. 5 können die Versicherten auch mittels einer eigenen Signaturkarte, die über eine qualifizierte elektronische Signatur verfügt, zugreifen. Zugriffsberechtigte Personen nach Absatz 4 Satz 1 Nr. 1 Buchstabe d und e sowie Nr. 2 Buchstabe d und e, die über keinen elektronischen Heilberufsausweis oder entsprechenden Berufsausweis verfügen, können auf die entsprechenden Daten zugreifen, wenn sie hierfür von Personen autorisiert sind, die über einen elektronischen Heilberufsausweis oder entsprechenden Berufsausweis verfügen, und wenn nachprüfbar elektronisch protokolliert wird, wer auf die Daten zugegriffen hat und von welcher Person die zugreifende Person autorisiert wurde. Der Zugriff auf Daten nach Absatz 2 Satz 1 Nr. 1 mittels der elektronischen Gesundheitskarte kann abweichend von den Sätzen 3 und 4 auch erfolgen, wenn die Versicherten den jeweiligen Zugriff durch ein geeignetes technisches Verfahren autorisieren. (6) Daten nach Absatz 2 Satz 1 Nr. 1 und Absatz 3 Satz 1 müssen auf Verlangen der Versicherten gelöscht werden; die Verarbeitung und Nutzung von Daten nach Absatz 2 Satz 1 Nr. 1 für Zwecke der Abrechnung bleiben davon unberührt. Durch technische Vorkehrungen ist zu gewährleisten, dass mindestens die letzten 50 Zugriffe auf die Daten nach Absatz 2 oder Absatz 3 für Zwecke der Datenschutzkontrolle protokolliert werden. Eine Verwendung der Protokolldaten für andere Zwecke ist unzulässig. Die Protokolldaten sind durch geeignete Vorkehrungen gegen zweckfremde Verwendung und sonstigen Missbrauch zu schützen. Abb. 3.28. Anforderungen an Datenschutz und Datensicherheit der elektronischen Gesundheitskarte79

 79

Sozialgesetzbuch (SGB) Fünftes Buch (V) – Gesetzliche Krankenversicherung – a.a.O.

86

3 Rechtliche Grundlagen des Information Lifecycle Management

§ 25a Besondere organisatorische Pflichten von Instituten 1 (1) Ein Institut muss über eine ordnungsgemäße Geschäftsorganisation verfügen, die die Einhaltung der von den Instituten zu beachtenden gesetzlichen Bestimmungen gewährleistet. 2 Die in § 1 Abs. 2 Satz 1 bezeichneten Personen sind für die ordnungs3 gemäße Geschäftsorganisation des Instituts verantwortlich. Eine ordnungsgemäße Geschäftsorganisation umfasst insbesondere

(…) angemessene interne Kontrollverfahren, die aus einem internen Kontrollsystem und einer internen Revision bestehen; das interne Kontrollsystem umfasst insbesondere geeignete Regelungen zur Steuerung und Überwachung der Risiken; (…) angemessene Sicherheitsvorkehrungen für den Einsatz der elektronischen Datenverarbeitung; eine vollständige Dokumentation der ausgeführten Geschäfte, die eine lückenlose Überwachung durch die Bundesanstalt für ihren Zuständigkeitsbereich gewährleistet; Buchungsbelege sind zehn Jahre und sonstige erforderliche Aufzeichnungen sechs Jahre aufzubewahren; § 257 Abs. 3 und 5 des Handelsgesetzbuchs gilt entsprechend; (…) Abb. 3.29. Besondere organisatorische Pflichten von Instituten nach KWG80

3.2.4.11 Das Kreditwesengesetz Hauptaufgaben des Gesetzes über das Kreditwesen (Kreditwesengesetz, KWG) sind die Sicherung und Erhaltung der Funktionsfähigkeit der Kreditwirtschaft sowie der Schutz der Gläubiger von Kreditinstituten vor Verlust ihrer Einlagen.

§ 1 (a) Begriffsbestimmungen (2) 1 Geschäftsleiter im Sinne dieses Gesetzes sind diejenigen natürlichen Personen, die nach Gesetz, Satzung oder Gesellschaftsvertrag zur Führung der Geschäfte und zur Vertretung eines Instituts in der Rechtsform einer juristischen Person oder einer Personenhandelsgesellschaft berufen sind. 2 In Ausnahmefällen kann die Bundesanstalt für Finanzdienstleistungsaufsicht (Bundesanstalt) auch eine andere mit der Führung der Geschäfte betraute und zur Vertretung ermächtigte Person widerruflich als Geschäftsleiter bezeichnen, wenn sie zuverlässig ist und die erforderliche fachliche Eignung hat; § 33 Abs. 2 ist anzuwenden. 3 Wird das Institut von einem Einzelkaufmann betrieben, so kann in Ausnahmefällen unter den Voraussetzungen des Satzes 2 eine von dem Inhaber mit der Führung der Geschäfte betraute und zur Vertretung ermächtigte Person widerruflich als Geschäftsleiter bezeichnet werden. 4 Beruht die Bezeichnung einer Person als Geschäftsleiter auf einem Antrag des Instituts, so ist sie auf Antrag des Instituts oder des Geschäftsleiters zu widerrufen. Abb. 3.30. Verantwortlichkeit gemäß § 1 (a) KWG81

 80

81

Gesetz über das Kreditwesen (Kreditwesengesetz – KWG) in der Neufassung der Bekanntmachung vom 9. September 1998 (BGBl. I S. 2776), zuletzt geändert durch Art. 4a des Gesetzes vom 22. September 2005 (BGBl. I S. 2809). Gesetz über das Kreditwesen (Kreditwesengesetz – KWG), a.a.O.

3.3 Bindende europäische (Rechts-) Vorschriften

87

§ 25a – Besondere organisatorische Pflichten von Instituten – regelt die für unser Buch relevanten Anforderungen an Datenverarbeitungssysteme und Aufbewahrung von Informationen (vgl. Abb. 3.29). Nach Absatz 1, Satz 5 sind sämtliche Buchungsbelege 10 Jahre, sämtliche sonstige erforderliche Aufzeichnungen sind 6 Jahre aufzubewahren, § 257 Absätze 3 und 5 des Handelsgesetzbuchs (s. Abb. 3.3) gelten entsprechend. Absatz 1 weist auch klar die Verantwortung für die Einhaltung der organisatorischen Anforderungen an die Institute zu durch den Verweis auf § 1 Abs. 2 Satz 1. Verantwortlich ist damit die natürliche Person des Geschäftsleiters.

3.3 Bindende europäische (Rechts-) Vorschriften 3.3.1 Empfehlungen des Baseler Ausschusses für Bankenaufsicht (Basel II) Motivation für Basel II ist die Sicherung einer angemessenen Eigenkapitalausstattung von Banken und die Schaffung einheitlicher Wettbewerbsbedingungen sowohl für die Kreditvergabe als auch für den Kredithandel. Basel II stellt die Nachfolgeempfehlungen für Basel I dar, auch als Baseler Akkord bezeichnet. Diese Nachfolgeempfehlungen resultieren aus einer Vielzahl von Kritikpunkten am Baseler Akkord, dazu gehören vor allem: 1. „Fehlallokation“ des aufsichtsrechtlichen Kapitals (berücksichtigt in Säule 1 des Basel II-Models). Da unter Basel I die Eigenkapitalunterlegung für Kredite an ein Kundensegment (z. B. Firmenkunden) unabhängig von der Bonität des Kreditnehmers erfolgte, bestand ein Anreiz, Kredite an Kunden mäßiger Bonität zu vergeben, weil bei diesen höhere Zinsen durchsetzbar waren und so ein größerer Gewinn auf das zu unterlegende Kapital erzielt werden konnte. 2. Einbeziehung weiterer Risiken (berücksichtigt in Säule 1 von Basel II). Unter Basel I mussten nur Marktpreisrisiken und Kreditrisiken mit Eigenkapital unterlegt werden. Die Erfahrung der letzten Jahre zeigt jedoch, dass eine Vielzahl von Bankenkrisen nicht durch diese Risiken, sondern durch operationelle Risiken ausgelöst wurde. So zum Beispiel die Pleite des UK Bankhauses Barings durch fehlerhafte Kontrollen des Händlers Nick Leeson in Singapur. Inoffiziell ist auch bekannt, dass – neben der faktischen Relevanz operationeller Risiken – die Erwartung geringerer Eigenkapitalanforderungen für Kreditrisiken dazu führte, eine Unterlegung der operationellen Risiken anzutreiben. 3. Mangelnde Konformität bei aufsichtsrechtlicher Prüfung und Veröffentlichung von Risikoinformationen (berücksichtigt in Säule 2 und 3 von Basel II). Bisher bestanden keine internationalen Standards für die aufsichtsrechtliche Prüfung in verschiedenen Ländern. Ebenso bestanden keine einheitlichen Standards, die die unternehmenseigene Veröffentlichung von risikorelevanten Informationen regelten.

88

3 Rechtliche Grundlagen des Information Lifecycle Management

Basel II besteht aus den drei sich gegenseitig ergänzenden Säulen: x Mindesteigenkapitalanforderungen x Bankaufsichtlicher Überprüfungsprozess x „Erweiterte Offenlegung“. 82 Die erste Säule bewertet das Kreditinstitut gemäß den eingegangenen Kredit-, Markt- und operationellen Risiken, die zweite Säule definiert die Überwachungsprozesse der jeweils nationalen Bankenaufsichtsbehörden, die dritte Säule des neuen Baseler Akkords postuliert umfangreiche Offenlegungspflichten über Eigenkapitalstruktur und Risikoengagement der Bank. Basel II wurde aktuell in der Europäischen Union zur bindenden Vorgabe erklärt. Die Umsetzung in deutsches Recht wird durch die „Mindestanforderungen an das Risikomanagement“ (MaRisk) für die „zweite Säule“ von Basel II sowie die Solvabilitätsverordnung (SolvV) für die „erste“ und „dritte Säule“ von Basel II erfolgen bzw. ist bei Erscheinung erfolgt. Internationale Ratingagenturen legen die Basel-II-Empfehlungen ihren Bonitätsgutachten zugrunde, das Bundesaufsichtsamt für Kreditwesen bestätigt deutschen Kreditinstituten, wenn sie Basel II erfüllen.83 Da Basel II zwar ein reines „Bankenregularium“ darstellt, die Risikobewertung der Bank jedoch stark von der ihrer Kunden abhängt, verlangen die Banken ein

Abb. 3.31. Der neue Baseler Akkord (Basel II)84

 82 83 84

http://de.wikipedia.org/wiki/Basel_II#Motive. Häuser, Franz: Bankenaufsicht in Europa – „Basel II“ als Perspektive, Leipzig, 2002, S. 19. http://de.wikipedia.org/wiki/Basel_II#Motive, a.a.O.

3.3 Bindende europäische (Rechts-) Vorschriften

89

dementsprechendes Kundenrating. Je besser das Rating des Kunden, umso geringer die Eigenkapitalunterlegung und umso günstiger wird ein Kredit. Die Konsequenz aus Basel II für ein Unternehmen mit Finanzierungsbedarf durch Banken ist, sich selbst einem Ratingverfahren zur Analyse und Bewertung des Unternehmensrisikos zu unterziehen. Dieses Rating bewertet das Unternehmensrisiko nach: x Marktposition (Strategie und Management, weiche Faktoren, hier kann auch das Informationsportfolio des Unternehmens bewertet werden), x Finanzielle Flexibilität, x Quantitative Analyse (WP-Berichte, Ergebnisse, Finanzplan), x Die für die quantitative Analyse benötigten Informationen finden wir in den aufzubewahrenden sonstigen Dokumenten gemäß HGB, GoBS, GDPdU, AktG, AO usw.

3.3.2 Solvency II Wenngleich aktuell in Sachen Solvency II noch viele Fragen offen sind, dürfte klar sein, dass Assekuranzen in Zukunft auf ein effizientes Risikomanagement verpflichtet werden. Auch Solvency II basiert analog zu Basel II auf einem DreiSäulen-Modell. Im Zusammenhang mit ILM ist insbesondere die zweite Säule mit zahlreichen Vorschriften mit Blick auf die Finanzaufsicht und das Risikomanagement sowie weiteren qualitativen Faktoren von Gewicht.

3.3.3 Die Good Manufacturing Practice der EU Unter der Good Manufacturing Practice (GMP) versteht man Richtlinien zur Qualitätssicherung der Produktionsabläufe und -umgebung. Für Hersteller medizintechnischer Produkte spielt die Qualitätssicherung eine zentrale Rolle, da hier Qualitätsabweichungen direkte Auswirkungen auf die Gesundheit der Verbraucher haben können. Durch ein GMP-gerechtes Qualitätsmanagementsystem ist die Gewährleistung der Produktqualität sicherzustellen und es werden die Anforderungen bestimmter Auslandsmärkte, z. B. USA, erfüllt. Entsprechende Richtlinien für den Arzneimittelbereich sind beispielsweise durch die europäische Kommission, durch das Pharmaceutical Inspection Co-Operation Scheme (PIC/S), durch die US-amerikanische FDA sowie auf globaler Ebene durch die International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) (bisher für Wirkstoffe und Qualitätsrisikomanagement) erstellt worden.85 Artikel 9, Absatz 2 der GMP  85

Vgl. Wikipedia, http://de.wikipedia.org/wiki/Good_Manufacturing_Practice; vgl. auch: EUDRALEX Volume 4 – Medicinal Products for Human and Veterinary Use: Good Manufacturing Practice, http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev4.htm; vgl. auch RICHTLINIE 2003/ 94/EG DER KOMMISSION vom 8. Oktober 2003 zur Festlegung der Grundsätze und Leitlinien der Guten Herstellungspraxis für Humanarzneimittel und für zur Anwendung beim Menschen bestimmte Prüfpräparate, aus Amtsblatt der Europäischen Union, L262/22 DE, vom 14.10.2003.

90

3 Rechtliche Grundlagen des Information Lifecycle Management

Artikel 9 Dokumentation (…) (2) Werden Daten nicht schriftlich, sondern mit elektronischen, fotografischen oder anderen Datenverarbeitungssystemen aufgezeichnet, so muss der Hersteller das System zunächst validieren, indem er nachweist, dass die Daten während des voraussichtlichen Aufbewahrungszeitraums ordnungsgemäß gespeichert werden. Die mit solchen Systemen gespeicherten Daten müssen schnell in lesbarer Form verfügbar gemacht werden können und werden den zuständigen Behörden auf Verlangen vorgelegt. Die elektronisch gespeicherten Daten werden durch Maßnahmen wie Duplizierung oder Backup und Übertragung in ein anderes Speichersystem gegen Datenverlust oder -beschädigung geschützt und Prüfungspfade werden eingerichtet. Abb. 3.32. Dokumentationspflichten gemäß der EU-GMP86

definiert die Anforderungen an die Speicherung und Aufbewahrung digital erfasster Daten. Hier werden Maßnahmen für Backup und Übertragung in ein anderes Speichersystem als Verfahren zum Schutz vor Datenverlust und -beschädigung gefordert. Annex 11 der GMP beschreibt diese Forderungen an computergestützte Systeme genauer. Prinzipiell soll sichergestellt werden, dass mit einem computergestützten System hinsichtlich Speicherung, Verteilung und Qualitätssicherung zumindest die gleiche Produktqualität und Qualitätssicherung wie in manuellen Verfahren erreicht wird. Die Validierung der computergestützten Systeme soll Bestandteil des gesamten Lebenszyklus des Computersystems sein. „This cycle includes the stages of planning, specification, programming, testing, commissioning, documentation, operation, monitoring and modifying".87 Zur Absicherung des Computersystems beschreibt Annex 11 folgende Anforderungen und Verfahren: x Das Computersystem muss in angemessenen Umgebungen ohne störende Einflüsse durch andere Faktoren lokalisiert sein. x Eine Systemdokumentation muss vorhanden und permanent aktualisiert werden. Diese muss die Prinzipien, Zielsetzungen, Sicherheitsmaßnahmen und den technischen Aufbau des Systems beschreiben sowie die Hauptmerkmale darstellen, wie das Computersystem verwendet wird und mit anderen Systemen und Prozessen interagiert. x Die eingesetzte Software muss einem Qualitätssicherungsprozess unterzogen worden sein. x Das System muss – wo sinnvoll – interne Prüfmechanismen zum Schutz vor Fehleingabe und -verarbeitung enthalten. x Wird ein manuelles System durch ein computergestütztes System ersetzt, so sind diese zur gegenseitigen Qualitätssicherung für einen sinnvollen Zeitraum parallel zu betreiben.  86 87

RICHTLINIE 2003/ 94/EG DER KOMMISSION vom 8. Oktober 2003, a.a.O. RICHTLINIE 2003/ 94/EG DER KOMMISSION vom 8. Oktober 2003, Annex 11, Absatz 2, a.a.O.

3.4 International relevante US-amerikanische Rechtsvorschriften

91

x Ein Autorisierungssystem unter Verwendung von Verschlüsselung, PassCards, persönlichen Codes und restriktivem Zugang zu Dateneingabegeräten sowie Prozeduren für Genehmigung, Änderung und Löschung von Benutzerrechten und die Veränderung von Benutzerpassworten müssen existieren, angewendet werden und die Protokollierung von Versuchen des unautorisierten Zugriffs ist durchzuführen. x Manuelle Einträge kritischer Daten unterliegen dem Vier-Augen-Prinzip. x Änderungen einmal eingegebener Daten dürfen nur von autorisiertem Personal durchgeführt werden und sollten protokolliert werden. Ein Audit-Trail sämtlicher Einträge und Änderungen von Daten wird empfohlen. x Jede signifikante Änderung am Computersystem oder verwendeter Software bedarf der Genehmigung durch den Verantwortlichen und muss vor Durchführung einer Validierung unterzogen werden. x Gedruckte Kopien elektronisch gespeicherter Daten müssen für Prüfzwecke erzeugt werden können. x Daten sollen elektronisch und physikalisch vor absichtlicher und unabsichtlicher Beschädigung geschützt sein. Gespeicherte Daten müssen hinsichtlich Verfügbarkeit, Persistenz und Korrektheit geprüft werden. Bei Änderungen am Computersystem oder Programmen müssen diese Prüfungen je nach eingesetzten Speichermedien in unterschiedlicher Häufigkeit durchgeführt werden. x Daten müssen in regulären Intervallen gesichert werden und – so lange erforderlich – in physikalisch separaten Räumen aufbewahrt werden. x Die Systeme müssen gemäß ihrer Bedeutung und der Notwendigkeit zur Verfügbarkeit durch alternative Möglichkeiten abgesichert werden [BusinessContinuity-Anforderung, die Autoren]. x Die für den Systemausfall benötigten Verhaltensprozeduren müssen definiert, validiert und aufgezeichnet werden. x Eine Prozedur zur Fehlererkennung und -analyse sollte vorhanden sein. x Übernehmen unternehmensfremde Gesellschaften Teile des Betriebes des Systems, so muss ein Vertrag [SLA, die Autoren] mit klar abgegrenzten Verantwortlichkeiten existieren. x Ein Release-Management für Batches muss existieren.88

3.4 International relevante US-amerikanische Rechtsvorschriften 3.4.1 Die Information Retention Laws Die US-amerikanischen Information Retention Laws korrespondieren mit den unterschiedlichen Aufbewahrungsregelungen der bis zu diesem Abschnitt vorgestellten deutschen und europäischen Gesetzgebung dahingehend, dass für  88

Vgl. RICHTLINIE 2003/ 94/EG DER KOMMISSION vom 8. Oktober 2003, Annex 11, Absatz 3 f., a.a.O.

92

3 Rechtliche Grundlagen des Information Lifecycle Management

unterschiedliche Branchen und innerhalb der Branchen für unterschiedliche Informationstypen unterschiedliche Aufbewahrungsdauern und -pflichten existieren. Die Information Retention Laws stellen in den USA genau wie hier über den ökonomischen Sinn der Aufbewahrung geschäftsrelevanter Informationen hinaus Gesetze, Regelwerke, Standards und weiter gehende Direktiven dar. Diese können, wie die Regularien der GoBS und des HGB branchenübergreifend sein – so müssen beispielsweise auch in den USA steuerrelevante Informationen aufbewahrt werden – können jedoch auch wie die Anforderungen aus dem Kreditwesengesetz sehr branchenspezifisch sein (auch in den USA müssen Bankinformationen aus Anforderungen der US-Notenbank aufbewahrt werden). Daraus folgt für den wirtschaftlichen Austausch mit dem US-amerikanischen Wirtschaftsraum die Notwendigkeit, dass einige hundert Gesetze bezüglich Datenaufbewahrung und Datenmanagement eingehalten werden müssen. Die Wichtigsten werden wir in den folgenden Abschnitten darstellen. Das US-Arbeitsministerium fordert in 29 CFR 516.6, Basis-Beschäftigungsdaten sowie Verdienstinformationen für 2 Jahre aufzubewahren. Diverse Daten zum Diskriminierungsverbot von Angestellten müssen für 3 Jahre und steuerrelevante Informationen für vier Jahre aufbewahrt werden. Dennoch definieren nicht sämtliche Aufbewahrungsregelungen feste Aufbewahrungsdauern. Der Federal Employee Compensation Act legt für Krankenhäuser und Ärzte fest, sämtliche Daten zu Unfällen aufzubewahren, darunter Beschreibungen, wie es zur Verletzung kam, eine Beschreibung der Art und des Ausmaßes der Verletzung sowie das Ergebnis der Diagnose(n). Wie lange diese Informationen aufbewahrt werden müssen, wird jedoch nicht spezifiziert. In solchen Fällen ist es für Unternehmen ratsam, adäquate Beratung zur Dauer der Aufbewahrung zu suchen. Hier ist auch zu prüfen, in welchem Format Informationen aufzubewahren sind, die eventuell unbegrenzt aufbewahrt und schnell verfügbar (lesbar) gemacht werden sollen. Als Beispiel für branchenspezifische Aufbewahrungspflichten, die über allgemeine gesetzliche Vorschriften hinausgehen, werden wir die Security and Exchange Commission Rules (SEC Rule) 17a-4 für Broker (Makler) und Dealer (Händler) darstellen. Unternehmen, die auf dem US-amerikanischen Markt präsent sind oder dies werden wollen, sollten ihre Datenhaltung und ihre Datenhaltungssysteme in sämtlichen Geschäftseinheiten einer gründlichen Analyse (Assessment) bezüglich der Aufbewahrungspflichten unterziehen, denen sie in ihrem geschäftlichen Umfeld unterworfen sind. Ferner sollte in einem solchen Assessment geprüft werden, ob die Aufbewahrungsdauer, das Format und der Aufbewahrungsort den amerikanischen Anforderungen entsprechen. So fordert beispielsweise die IRSRegel 26 CFR 31.6001-189, dass steuerrelevante Daten an einem oder mehreren  89

Das IRS (Internal Revenue Service) des Department of Treasury (US-Finanzministerium) vertritt den US-Finanzminister in seiner Aufgabe, gemäß dem Internal Revenue Code die Einhaltung der Regularien der Finanzgesetzgebung zu überwachen und die Besteuerung durchzuführen. In dieser Funktion ist das IRS den deutschen Finanzbehörden gleichzusetzen.

3.4 International relevante US-amerikanische Rechtsvorschriften

93

sicheren und der Datenhaltung entsprechenden Orten zum ständigen Zugriff durch interne Revision und jederzeit verfügbar für Prüfzwecke aufbewahrt werden müssen. Die Datenhaltungssysteme werden – wie bei den bereits vorgestellten deutschen und europäischen Vorschriften auch – für bestimmte Zwecke hinsichtlich ihrer Struktur und Funktionalität präzise beschrieben. So fordert das IRS von Finanzinstituten, so sie ihre Daten in elektronischer Form speichern und bearbeiten, die Einhaltung bestimmter Kriterien durch die Datenhaltungs- und -verarbeitungssysteme: x Das Datenhaltungs- und Datenverarbeitungssystem muss ein Retrievalsystem beinhalten, das sämtliche Informationen, die in das System einfließen, indiziert, speichert, sichert, wiederherstellt und reproduziert. x Das Datenhaltungs- und Datenverarbeitungssystem muss seinem Zwecke entsprechende Mechanismen zur internen Kontrolle, Qualitätssicherung und zur Gewährleistung der Integrität, Zuverlässigkeit und Persistenz des Systems enthalten. x Das Datenhaltungs- und Datenverarbeitungssystem muss sicherstellen, dass die in ihm gespeicherten Informationen mit denen der Unternehmensbücher übereinstimmen, und einen Audit-Trail der Quelldokumente ermöglichen. Außerdem müssen Unternehmen auf dem US-amerikanischen Markt sicherstellen, dass sie ihre definierten und fixierten Informationsmanagement-Praktiken und -Prozesse auch beim Löschen von Daten einhalten, wenn deren Aufbewahrungsperiode abgelaufen ist. In all diesen Regularien weichen die US-amerikanischen Anforderungen nicht sehr stark von den bundesdeutschen Gesetzen und Verordnungen ab. Die GoBS, GDPdU, das Kreditwesengesetz und die bereits beschriebenen deutschen und europäischen Vorschriften regeln die zu den US-amerikanischen korrespondierenden Aufbewahrungspflichten, -dauern und Anforderungen an die Datenhaltungssysteme. Die Details unterscheiden sich jedoch teilweise, so dass eine Compliance zu deutscher oder europäischer Rechtsprechung nicht unbedingt die Compliance zu US-amerikanischem Recht beinhaltet. Ein Assessment zur Compliance zum US-amerikanischen Recht ist unseres Erachtens für Unternehmen unabdingbar, die auf dem US-amerikanischen Markt tätig sind oder werden wollen.

3.4.2 Die Privacy Laws Privacy Laws regeln die Reaktion auf Datenverlust oder – weitaus relevanter – potenziellen Datendiebstahl durch Hacker. Als erster US-amerikanischer Staat reagierte Kalifornien mit dem California Database Protection Act auf den Einbruch von Hackern in die Personaldatenbank des Staates Kalifornien, bei dem persönliche Daten und Gehaltsdaten von 250.000 Angestellten des Staates Kalifornien von „Identitätsdiebstahl“ bedroht waren. Der California Database Protection Act verpflichtet jegliche Organisation, die personenbezogene Daten speichert und

94

3 Rechtliche Grundlagen des Information Lifecycle Management

verarbeitet, zu diversen Formen persönlicher Information von kalifornischen Staatsbürgern, wenn eine Sicherheitslücke bezüglich ihrer gespeicherten Informationen aufgetreten ist, solange diese Daten nicht in verschlüsselter Form gespeichert sind. Diese persönliche Information hat unverzüglich und ohne unbegründbare Verzögerung zu erfolgen, unabhängig davon, ob tatsächlich Daten gestohlen wurden oder nicht. Zwischenzeitlich haben 35 US-amerikanische Staaten dem California Database Protection Act vergleichbare Privacy Laws erlassen, ähnliche Gesetzesvorlagen wurden bereits in den Kongress eingereicht, um eine vergleichbare nationale Regelung zu erreichen. Dies bedeutet für jedes Unternehmen, das auf dem US-amerikanischen Markt aktiv ist, eine Überprüfung der Sicherheitskonzepte für seine Datenhaltungsund -verarbeitungssysteme. Neuerliche Vorfälle wie der eines Finanzinstituts, bei dem SicherungsMagnetbänder mit den personenbezogenen Daten von mehr als drei Millionen Kunden abhanden gekommen sind, oder der Fall eines Telekommunikationsunternehmens, bei dem Magnetbänder mit personenbezogenen Daten seiner 600.000 Mitarbeiter verloren gingen oder der bedeutendste Fall, bei dem Hacker den Zugriff auf 40 Millionen Kunden eines Kreditkartenunternehmens erhielten, führten dazu, dass die Privacy Laws in diesen Tagen auch auf verschlüsselte Daten angewendet werden.

3.4.3 Die Food and Drug Administration 21 CFR Part 11 1997 veröffentlichte die Food and Drug Administration (FDA) die Rule 21 CFR Part 11, die den von der FDA regulierten Branchen (pharmazeutische Industrie, Biotechnologie, Medizingeräte, Lebensmittelherstellung) die Verwendung elektronischer Datenhaltungs- und -verarbeitssysteme und elektronischer Signaturen für Geschäftszwecke genehmigte.90 Part 11 enthält detaillierte Anforderungen an die Verwendung und Administration von elektronischen Datensätzen mit der Absicht, den größtmöglichen Einsatz elektronischer Technologien zuzulassen, der mit der Verantwortung der FDA für die öffentliche Gesundheit konform geht. Wenn auch Part 11 den Gebrauch elektronischer Technologien zulässt, so bevollmächtigt die FDA mit Part 11 keineswegs die von ihr regulierten Institutionen zur Verwendung elektronischer Datensätze. Part 11 – ebenso wie die GMP der Europäischen Union – erlaubt bestenfalls die Anwendung und Aufbewahrung elektronischer Datensätze und Signaturen anstelle papierner Dokumente. Dabei werden durch Part 11 diverse strenge Anforderungen an Gebrauch und Aufbewahrung digitaler Daten gestellt: x Computersysteme und -software, die elektronische Daten verarbeiten, administrieren und speichern, müssen einem Validierungsprozess unterworfen werden.  90

Korrespondiert mit Medizingeräteverordnung, Röntgenverordnung, GMP.

3.4 International relevante US-amerikanische Rechtsvorschriften

95

x Es müssen Kontrollprozeduren und Sicherheitsmaßnahmen vorhanden sein, die elektronische Daten schützen und deren Korrektheit und Vertrauenswürdigkeit garantieren. x Datensätze müssen zu Kontrollzwecken durch die FDA jederzeit zugreifbar sein. x Es müssen Autorisierungsverfahren und Sicherheitsmaßnahmen zum Schutz vor unautorisiertem Zugriff auf Daten vorhanden sein. x Sichere, elektronisch erzeugte, mit Zeitstempel versehene Audit-Trails müssen aufgezeichnet werden. Dies beinhaltet auch Protokolle zum Einsatz elektronischer Signaturen. x Die Verwendung elektronischer Signaturen muss in einer schriftlichen Firmen-Policy beschrieben sein. Die FDA unterstützt sämtliche von ihr kontrollierten Branchen bei der Erreichung des Compliance-Ziels, indem sie ihnen bezüglich Part 11 eine „Guidance“ zur Verfügung stellt, deren aktuellste Fassung jeweils für die Entwicklung, Implementierung und Wartung der Informationssysteme verwendet werden sollte. Die aktuelle Guidance ist vom August 2003 datiert und im Internet verfügbar unter: http://www.fda.gov/cber/gdlns/prt11elect.pdf. In dieser Guidance wird den von der FDA regulierten Organisationen dringend geraten, sicherzustellen, dass die IT-Security-Überlegungen aus drei Faktoren bestehen müssen: 1. Die Erfüllung der Anforderungen von 21 CFR Part 11. 2. Das Vorliegen einer detaillierten Risikoanalyse (Risk Assessment). 3. Eine Bewertung der potenziellen Auswirkungen, die diese Risiken bei ihrem Eintreten für die Integrität der Unternehmensdaten bergen. Zusätzlich zu sämtlichen technischen Maßnahmen zur Gewährleistung der Erfüllung der Anforderungen aus Part 11 sind organisatorische Maßnahmen administrativer und prozeduraler Art erforderlich, um eine Compliance gemäß 21 CFR Part 11 zu erreichen. So müssen sämtliche Policies und Prozesse einem beständigen Qualitätssicherungsprozess unterzogen werden. Es sollte eine periodisch wiederkehrende Risikoanalyse und ein Risikomanagement durchgeführt werden bis hin zu Audits der IT-Unternehmenssysteme durch unabhängige Organisationen. Verstöße gegen Part 11 werden durch die Regulierungsbehörde verfolgt, eine Änderung angemahnt. Bei wiederholten Verstößen gegen Part 11 können seitens der FDA hohe Geldstrafen ausgesprochen werden. Außerdem kann die Herstellung einzelner Produkte untersagt, ja es können sogar komplette Produktionen stillgelegt werden.

3.4.4 Der Health Insurance Portability and Accountability Act (HIPAA) Der HIPAA von 1996 stellt das ausführlichste Gesetzeswerk für das US-amerikanische Gesundheitswesen seit den 60er Jahren des 20. Jahrhunderts dar. Es

96

3 Rechtliche Grundlagen des Information Lifecycle Management

erweitert die Regularien der in Abschnitt 3.4.2 dargestellten Privacy Laws um spezielle Anforderungen an die Speicherung, das Management und die Verarbeitung personenbezogener Daten im Gesundheitssystem.91 HIPAA ist in drei Hauptabschnitte untergliedert, die – jeder für sich – eine Vielzahl an Anforderungen an das Management gesundheitsbezogener Daten stellen. Die von der HIPAA regulierten Organisationen müssen: 1. den Austausch digitaler Daten, bezogen auf Transaktionen, im Gesundheitssystem standardisieren, 2. personenbezogene Daten, insbesondere individuelle Gesundheitsinformationen, schützen, 3. die Sicherheit personenbezogener Daten gewährleisten, insbesondere die Sicherheit individueller Gesundheitsinformationen. Seit Inkrafttreten der Security Rule (vgl. Punkt 3) im April 2005 sind sämtliche Abschnitte des HIPAA rechtskräftig. HIPAA beschreibt mit dem Begriff „covered entities“ die Organisationen im Gesundheitswesen, die individuelle Gesundheitsinformationen sammeln und verwalten. Dazu gehören insbesondere Krankenversicherungsgesellschaften, (Beitrags-) Verrechnungsstellen und Gesundheitsanbieter (Krankenhäuser, Ärzte, Apotheken, aber auch Pharmaunternehmen, Sanitärproduzenten usw.), die personenbezogene Gesundheitsdaten erhalten, speichern und verarbeiten. Wird die Verarbeitung, Speicherung und Administration personenbezogener Gesundheitsdaten an externe Dienstleister vergeben, so haftet der Auftraggeber für die Noncompliance des beauftragten Unternehmens zu HIPAA, so er nicht maßgebliche Schritte unternimmt, die Noncompliance des Auftragnehmers zu beseitigen. Die oben genannten Unternehmen und Organisationen gehören per se zu den vom HIPAA betroffenen. HIPAA gilt aber auch für solche Unternehmungen und Organisationen, die beispielsweise personenbezogene Gesundheitsdaten von Mitarbeitern halten oder Gesundheits- und Vorsorgepläne von Mitarbeitern verwalten. So können Unternehmen, die für Mitarbeitergruppen Krankenversicherungen anbieten (vergleichbar mit deutschen Betriebskrankenkassen, die jedoch bei weitem nicht mehr so eng in das Unternehmen eingebunden sind wie US-amerikanische Gruppenversicherungen) dennoch zur Compliance mit dem HIPAA verpflichtet sein. HIPAA fordert von den regulierten Organisationen hohe Anstrengungen bezüglich ihrer Policies und Prozesse zum Informationsmanagement und stellt hohe Anforderungen an die verwendeten IT-Systeme. So müssen gemäß der Security Rule der HIPAA physikalische, technische und administrative Sicherungen implementiert sein, um jeden unautorisierten Zugriff, jede Modifikation von Daten oder Datenkorrumption zu verhindern. Die „covered entities“ müssen einen Sicherheitsbeauftragten (Einzelperson oder Abteilung) unterhalten, der in regelmäßigen Assessments die Einhaltung der Security Rule überprüft. Zusätzlich  91

Vergleichbar mit den Regelungen des SGB.

3.4 International relevante US-amerikanische Rechtsvorschriften

97

muss ein detailliertes Sicherheitssystem erstellt und dessen Effektivität zertifiziert werden (vgl. BSI-Grundschutz). Die IT-Systeme müssen über diverse Zugriffsschutzmechanismen für den Zugriff von Mitarbeitern verfügen, die den entwickelten Policies, Prozessen und Richtlinien für die Mitarbeiter entsprechen. HIPAA schreibt keine Technologien für die Compliance vor. Ebenso gibt es mehrere Möglichkeiten, HIPAA-konforme Policies und Prozeduren zu entwickeln, die nicht allein die digitale Sicherheit gewährleisten, sondern auch noch Business Continuity und Disaster-Recovery-Schutz anbieten. Auf jeden Fall sollten auch hier nach einem detaillierten Assessment die notwendigen Maßnahmen zur HIPAA-Compliance ergriffen werden. Bei Verstößen gegen HIPAA werden jährliche Ordnungsgelder von bis zu 25.000,- US $ pro verletztem Standard und Strafen von bis zu 250.000,- US $ und/oder Haftstrafen von bis zu 10 Jahren bei mutwilligem Missbrauch personenbezogener medizinischer Daten verhängt.

3.4.5 Der Gramm-Leach-Bliley Act (GLB) Der GLB ist auch als Financial Services Modernization Act von 199992 bekannt. Er brachte wesentliche Veränderungen in die Art und Weise, wie Finanzinstitute ihre Daten behandeln und mit personenbezogenen Daten ihrer Kunden und Geschäftspartner operieren. So müssen Finanzinstitute nach GLB ihren Kunden offen legen, wie und wohin deren Daten weitergegeben werden, und darauf hin weisen, dass die Kunden dieses Data Sharing limitieren können. Außerdem gibt GLB den Kunden von Finanzinstituten die Möglichkeit, diverse Prozeduren zur Datenweitergabe durch die Finanzinstitute „abzuwählen“. Acht Bundesagenturen wachen gemäß GLB Section 504 und 505 mit einem regulatorischen Maßnahmenkatalog über die Einhaltung von GLB. Zu den regulatorischen Maßnahmen gehören die Regulation S-P der Securities and Exchange Commission (SEC) sowie die Safeguards Rule der FTC (Federal Trade Commission). Diese fordern von Finanzinstituten die Implementierung von tragfähigen Policies und Prozessen zur Gewährleistung der Sicherheit personenbezogener Daten. Der Gramm-Leach-Bliley Act betrifft nicht allein die klassischen Finanzinstitute wie Banken, Versicherungen und (Börsen-) Makler, sondern auch Leasing-Gesellschaften, Unternehmen, die Scheckzahlungen akzeptieren, sowie sämtliche Unternehmen, die ihren Kunden ein Kundenkreditkonto gewähren. Prinzipiell sind die Anforderungen des GLB sowie die Anwendungsverordnungen der regulierenden Verwaltungen für sämtliche Finanzinstitute bindend, die aktiv oder passiv personenbezogene Daten finanzieller Natur erhalten oder diese Informationen mit anderen finanzwirtschaftlich tätigen Unternehmungen teilen.  92

Vergleichbar mit dem deutschen Kreditwesengesetz in Verbindung mit den Mindestanforderungen für Handelssysteme.

98

3 Rechtliche Grundlagen des Information Lifecycle Management

So regeln die Anwendungsverordnungen der FTC Safeguard Rule, dass betroffene Finanzinstitute prüfbare Sicherheitsvorkehrungen zum Schutz personenbezogener Daten entwickeln müssen. Diese beinhalten: x Einführung eines Sicherheitsplans zum Schutz personenbezogener Daten, x Durchführung einer Risikoanalyse und Fortschreibung des Sicherheitsplans gemäß den Ergebnissen der Risikoanalyse, x Implementierung eines oder mehrerer Sicherheitsbeauftragten bzw. Sicherheitsbeauftragter, x Regelmäßige Qualitätssicherung und Risikomanagement des Sicherheitssystems sowie permanente Fortschreibung des Sicherheitsplans. Die FTC Safeguard Rule fordert vom Finanzinstitut ein Sicherheitssystem, das der Größe und Komplexität sowie dem Inhalt seiner Aktivitäten entspricht. Die SEC Regulation S-P fordert einen initialen Bericht und danach jährliche Berichte über die Policies und Praktiken des Finanzinstitutes zur Gewährleistung des Schutzes personenbezogener Daten sowie Berichte über Möglichkeiten und Verfahren für Kunden des Finanzinstitutes, die Weitergabe personengebundener Informationen durch das Finanzinstitut zu beschränken. Auch die SEC Regulation S-P fordert ein dem Finanzinstitut adäquates Sicherheitssystem. Diese Formulierung impliziert, dass jedes dem GLB unterliegende Finanzinstitut, wohl daran tut, sich hinsichtlich der Compliance zu GLB juristisch beraten zu lassen. Sämtliche Regulierungsbehörden haben die Möglichkeit, bei Verletzung der Compliance empfindliche, auch organisatorisch wirksame Eingriffe in das Geschäft des betroffenen Finanzinstitutes vorzunehmen.

3.4.6 Die Federal Rules of Civil Procedure Die Federal Rules of Civil Procedure (FRCP)93 sind Anordnungen für Zivilprozesse, die an US-Bundesgerichten verhandelt werden. Jede der dreizehn Sektionen dieser „Zivilprozessordnung“ enthält Regularien für Dokumentenverwendung, Dokumentenaufbewahrung und Sicherung von Dokumenten. So enthält beispielsweise Section 2 Regeln für die Aufbewahrung von Plädoyers und anderen Dokumenten, Section 5 enthält Regeln für die Beweiskraft elektronischer Dokumente. Als eventuell beweiskräftiges Dokument definieren die FRCP Schriftstücke, Zeichnungen, Grafiken, Karten, Fotografien, Tonaufzeichnungen sowie andere Aufzeichnungen von Daten, aus denen Informationen gewonnen werden können und die – falls notwendig – in sinnvoll nutzbare Form zu übertragen sind. Mit dieser breiten Definition der „anderen Aufzeichnungen von Daten“ müssen die Verantwortlichen eines in den USA tätigen Unternehmens sich darüber im Klaren sein, dass nahezu sämtliche gespeicherten Informationen als potenzielle Beweismittel in Zivilprozessen herangezogen werden können. Daher sollte jedes Unternehmen einen Vorgehensplan für drohende Rechtsstreitigkeiten  93

Vergleichbar der deutschen Zivilprozessordnung.

3.4 International relevante US-amerikanische Rechtsvorschriften

99

entwickeln, um sicherzustellen, dass es den rechtlichen Verpflichtungen Genüge tut. Ein solcher Vorgehensplan sollte auf jeden Fall folgende Aspekte beinhalten: 1. Es sollte ein Assessment der Information Management Policies und Prozesse des Unternehmens durchgeführt werden, um sicherzustellen, dass für den Fall von Ermittlungen sämtliche Daten aufgefunden, aufbereitet und präsentiert werden können. 2. Die Implementierung einer effektiven Legal Hold Policy (zugelassene Einflussnahme), die die Zerstörung von Daten und Informationen aufgrund von Routineprozessen oder auch anderen Gründen verhindert. 3. Die Implementierung eines Legal-Hold-Prozesses, der Mitarbeiter und andere Personen wirkungsvoll über ihre Verantwortung für die Aufbewahrung zivilrechtlich relevanter Informationen informiert. 4. Durchführung einer Analyse der IT-Infrastruktur des Unternehmens, um sicherzustellen, dass diese den Legal-Hold-Prozess unterstützen kann und sämtliche zivilrechtlich relevante Daten aufbewahrt, ohne die Geschäftsprozesse zu behindern. 5. Aufbau von Wissensträgern innerhalb des Unternehmens, die für jeweils ihren Verantwortungsbereich genau wissen, wie die zivilrechtlich relevanten Informationen zugegriffen und aufbereitet werden müssen, in welchem Format sie vorliegen und wo sie zu generieren sind. Um sicherzustellen, dass im Falle von Rechtsstreitigkeiten das elektronische Suchen nach beweiskräftigen Informationen das Tagesgeschäft nicht behindert, sollten Unternehmen nach einem Verfahren suchen, zivilrechtlich relevante Informationen abzutrennen und über einen Lifecyclemechanismus für elektronische richterliche Auskunftsersuchen zugreifbar zu machen.

3.4.7 Der Electronic Signatures in Global and National Commerce Act (E-SIGN) Der E-SIGN Act von 2000 klärt die rechtliche Gültigkeit von elektronischen Signaturen und digitalen Daten für Transaktionen zwischen den Staaten der USA und internationale Transaktionen. Hier werden elektronische Signaturen und digitale Daten als zusätzliche rechtsverbindliche Aussagen zugelassen, indem ihnen nicht von vornherein eine rechtskräftige Verbindlichkeit abgesprochen wird, nur weil sie in elektronischer Form vorliegen. E-Signatures und E-Records können nach dem E-SIGN Act nun weitaus mehr als je zuvor als Ersatz für ihre handschriftlichen Pendants eingesetzt werden. E-SIGN ist gültig für staatenübergreifende Transaktionen. Transaktionen innerhalb einzelner Bundesstaaten werden weitgehend durch Staatsgesetze geregelt. Diese basieren nahezu alle auf dem Uniform Electronic Transaction Act (UETA). E-SIGN fordert von Unternehmen und Organisationen, die geschäftlich mit Verbrauchern korrespondieren, klare und dem Verbraucher auffallende Hin-

100

3 Rechtliche Grundlagen des Information Lifecycle Management

weise auf deren Rechte im Zusammenhang mit der Verwendung von Informationen im elektronischen oder nicht elektronischen Format. Auch wenn E-SIGN die Verwendung digitaler Daten anstelle papierner Dokumente erlaubt, so wird durch E-SIGN keine Hilfestellung für Unternehmen und Organisationen gegeben, wie diese die elektronischen Daten erstellen, aufbewahren und verwalten sollen. So bleibt stets die Möglichkeit, dass die Vertraulichkeit und die Zugreifbarkeit auf Daten im Datenhaltungssystem von Unternehmen in Zweifel gezogen werden kann. Zweifel wirken sich auch auf die Rechtswirksamkeit, Gültigkeit oder Durchsetzbarkeit digitaler Daten aus. Diese können laut E-SIGN versagt werden, wenn elektronische Daten nicht in einer Form vorgehalten werden, die deren Aufbewahrung und präzise Wiederherstellung zur Referenz durch sämtliche Personen und Parteien ermöglichen, die ein Anrecht auf einen Vertrag oder andere Daten besitzen. Diese recht frei auszulegende rechtliche Vorschrift wird durch die Definition einer elektronischen Signatur noch verstärkt, die definiert wird als elektronisches Geräusch, Symbol oder Prozess, der an einen Vertrag oder eine Information angehängt oder logisch mit diesem/r verbunden ist mit der Absicht, diese/n zu unterschreiben. Aus diesen interpretierbaren Regelungen ergibt sich die Notwendigkeit, die Verwendung elektronischer Signaturen und E-Records rechtlich dadurch abzusichern, dass zumindest folgende Aspekte untersucht und dokumentiert werden: 1. Prüft der Prozess zur elektronischen Unterschrift, wer ein Dokument unterschreibt (und ob diese Person dazu berechtigt ist), wann das Dokument unterschrieben wurde und warum es unterschrieben wurde? 2. Erzeugt der Prozess einen vollständigen und korrekten elektronischen Datensatz? Ist mit diesem Datensatz die geschäftliche Transaktion konsistent abgebildet? 3. Berücksichtigt der Prozess, dass die Verwendung elektronischer Prozesse für geschäftliche Transaktionen der Zustimmung der Kunden bedarf, und gewährleistet er, dass diese jederzeit auf ihre digital gespeicherten Daten zugreifen können? 4. Werden die elektronisch gespeicherten Geschäftsvorfälle für die Dauer ihrer Aufbewahrungszeit jederzeit zugreifbar sein? Auch wenn E-SIGN nicht klar spezifiziert, welche Information zu Geschäftsvorfällen in welchem Format gespeichert und als Ersatz für papierne Dokumente verwendet werden darf, werden einige Dokumente doch klar von E-SIGN ausgeschlossen. So bedürfen auch nach E-SIGN Willenserklärungen sowie Benachrichtigungen bezüglich gerichtlicher Verfallserklärungen schriftlicher papierner Form.

3.4.8 COBIT und COSO Das Control Objectives for Information and Related Technologies (COBIT-) Framework wurde 1996 vom IT Governance Institute (ITGI) für Unternehmen

3.4 International relevante US-amerikanische Rechtsvorschriften

101

als Best-Practices-Sammlung zur Geschäftsprozessoptimierung ihrer IT herausgegeben. Das COBIT-Framework ist in Kap. 8.5.1.7 detailliert dargestellt. Insgesamt werden im COBIT-Framework über 300 Feinkontrollziele und 34 Grobkontrollziele beschrieben, die Organisationen darin unterstützen sollen, ihre IT-Ressourcen in einem Framework zu verwalten, das optimale Planung und Organisation, Beschaffung und Implementierung, Auslieferung und Wartung sowie Performanceüberwachung integriert. Zielsetzung von COBIT ist dabei die Entwicklung effektiver Policies und Practices für IT-Sicherheit und Controlling für die IT-Prozesse von kommerziellen, öffentlichen und freiberuflichen Organisationen weltweit. Das Committee of Sponsoring Organizations of the Treadway Commission (COSO) untersucht seit 1985 die Faktoren, die zu fehlerhaften Finanzreporten und fehlerhafter Bilanzierung führen. Ergebnis ist ein Framework (im Wesentlichen für Kapitalgesellschaften), Auditoren und Regulatoren, das auf die Entwicklung eines internen Controllings fokussiert ist. Dieses soll sowohl Geschäfts-, Betriebs-, Finanz-, aber auch Compliance-Ziele erfüllen. Dabei definiert COSO internes Controlling als einen vom Management eines Unternehmens ins Leben gerufenen Prozess, um die Geschäftsziele in drei wesentlichen Kategorien zu erreichen: 1. Effektivität und Effizienz des Geschäftsbetriebes, 2. Zuverlässigkeit des Finanzreportings/der Bilanzierung und 3. Einhaltung auf das Unternehmen zutreffender Gesetze und Regularien. Damit stellen sowohl COSO als auch COBIT den Unternehmen ein Werkzeug zur Verfügung, mit dem sie sowohl ihre Geschäftsziele erreichen als auch die juristischen und sonstigen öffentlichen Anforderungen einhalten können.

3.4.9 Regelungen des Sarbanes-Oxley Act (SOX) Der Sarbanes-Oxley Act von 2002 wurde zu einem Zeitpunkt rechtskräftig, als die ersten konkreten Vermutungen zu einigen Unternehmensskandalen laut wurden, die kurze Zeit später um die Welt gingen (ENRON, MCI). Er dient dazu, Aktionäre zu schützen und die Exekutive bei der Verfolgung und Bestrafung von Falschbilanzierungen zu schützen. Insofern ist in Deutschland das TransPubG in Verbindung mit dem KonTraG mit dem Sarbanes-Oxley Act vergleichbar. SOX zielt im Wesentlichen auf Corporate Governance, Buchhaltung und Bilanzierung von Kapitalgesellschaften. Dennoch zieht dies ebenfalls Änderungen im Informationsmanagement der börsennotierten Unternehmungen nach sich. So müssen nach SOX Chief Executive Officers (CEO) und Chief Financial Officers (CFO) börsennotierter Unternehmungen die Korrektheit der veröffentlichten Finanzinformationen und Bilanzen erklären und sind somit persönlich haftbar zu machen, falls diese Erklärung nicht der Realität entspricht. Dies sorgt für die Implementierung eines internen Controllings, das die Korrektheit dieser Informationen für die Öffentlichkeit garantiert.

102

3 Rechtliche Grundlagen des Information Lifecycle Management

Darüber hinaus stellt der Sarbanes-Oxley Act die Zerstörung oder Verfälschung von geschäftsrelevanten Informationen unter Strafe, falls durch diese eine öffentliche Kontrolle der Kapitalgesellschaften behindert wird. Der Sarbanes-Oxley Act gilt zwar ursprünglich nur für die US-amerikanischen und internationalen Kapitalgesellschaften, die an der US Stock Exchange gelistet sind. Dennoch werden de facto dessen Anforderungen auch auf Kapitalgesellschaften angewendet, die zwar nicht börsennotiert sind, die jedoch aufgrund eines Fremdkapitalbedarfs oder durch Kunden- bzw. Geschäftspartneranforderung sich auch den Praktiken gemäß SOX angleichen müssen. Neben der durch SOX festgestellten besonderen Sorgsamkeitspflicht des Managements für die Korrektheit der Finanzreports fordert Section 404 zusätzlich den Aufbau eines Risikomanagements inklusive der Selbsteinschätzung der Geschäftsrisiken, die das finanzielle Ergebnis des Unternehmens beeinflussen können, sowie die Einrichtung und Dokumentation eines internen Kontrollsystems (vgl. COBIT und COSO). Ferner müssen die Verfahren zur Erstellung des Finanzreports dargestellt und dokumentiert werden. Überwacht wird die Compliance zum Sarbanes-Oxley Act durch die US Securities and Exchange Commission (SEC), die US-amerikanische Börsenaufsicht. Konsequenzen des Sarbanes-Oxley Act für das Informationsmanagement börsennotierter Unternehmungen sind immens. So steht das Information Management aufgrund der Verantwortung der Unternehmensspitze unter erhöhter Beobachtung. Die Qualität der Daten, ihre Vollständigkeit und Integrität sind Kernpunkte für korrekte Finanzreports. Aufgrund SOX geht die IT in der Zwischenzeit in US-amerikanischen börsennotierten Unternehmungen in ein Vorstandsressort ein und fristet daher kein Dasein mehr als eine untergeordnete (Haupt-) Abteilung ihrer Gesellschaft.

3.4.10 Die SEC Rule 17a-4 Der Securities and Exchange Act von 1934 reguliert den Finanzbereich der Vereinigten Staaten. Unter anderem wird darin die Erstellung und Pflege von Transaktionen von Sicherheiten gefordert, um Investoren und US-Wirtschaft durch die Möglichkeit von Reviews und Audits vor finanziellen Verlusten zu schützen. SEC Rule 17a-4, genauer 17 CFR 249.17a-4, wurde von der US-Börsenaufsicht (SEC) auf der Basis des Securities and Exchange Act erzeugt, um die Anforderungen an die Datenhaltung für einige Teilnehmer am Finanzmarkt (Broker und Dealer) festzulegen. Im Jahre 1997 wurde diese Regel novelliert, um – bei Erfüllung bestimmter Voraussetzungen – die Speicherung, Aufbewahrung und Wiederherstellung von Informationen in elektronischer Form ihrem Pendant in papierner Form gleichzusetzen. Die wesentlichen Anforderungen aus SEC Rule 17a-4 sind: 1. Börsenmitglieder, Broker und Dealer bewahren für einen Zeitraum von nicht weniger als drei Jahren – darunter für die ersten beiden Jahre an einem leicht zugänglichen Ort [physikalischem Speicherort, die Autoren] – die Originale sämtlicher erhaltener und Kopien sämtlicher versendeter Dokumente

3.4 International relevante US-amerikanische Rechtsvorschriften

2.

3. 4.

5.

103

einschließlich der elektronischen Kommunikation wie E-Mails und Instant Messaging auf, die einen Bezug zu ihrer Tätigkeit als Broker und Dealer besitzen. Es dürfen lediglich elektronische Medien zu deren Aufbewahrung verwendet werden, die diese Daten in einem nicht zu verändernden und nicht zu löschenden Format aufbewahren. Genannt ist hier explizit eine WORMTechnologie (Write Once Read Many). Die verwendeten elektronischen Speichermedien verifizieren automatisch die Qualität und Korrektheit des Aufzeichnungsprozesses der Daten. Sämtliche Mitglieder, Broker und Dealer halten bestimmte elektronische Informationen für den jederzeitigen, direkten Zugriff durch ein Review der SEC über Projektion oder Produktion zur Verfügung. Zusätzlich zum Original muss von jedem Mitglied, Broker oder Dealer ein Duplikat des Originals auf einem akzeptablen Medium für die Dauer der Aufbewahrungsfrist gespeichert werden.

3.4.11 Die Regelungen des DoD 5015.2 Die Direktive 5015.2 des US-amerikanischen Verteidigungsministeriums (DoD) zum "Department of Defense Records Management Program" vom 06. März 2000, gibt eine Implementierungs- und prozedurale Hilfestellung für das Management von Datensätzen im Department of Defense. Dieser Standard definiert verpflichtend grundlegende funktionale Anforderungen an Datenhaltungssoftware (Records Management Application (RMA)), die von DoD Komponenten zur Implementation ihrer Datenverwaltungs- und Datenhaltungsprogramme verwendet werden. Sie definiert unbedingt notwendige Systemschnittstellen und Suchkriterien, die durch die RMAs unterstützt werden müssen. Letztlich beschreibt sie die Minimalanforderungen, die eine Datenhaltung auf Grundlage des aktuellen Regelwerks der National Archives and Records Administration (NARA) erfüllen muss. Die in der DoD-Direktive 5015.2 definierten Standards sind aufgegliedert in: 1. Anforderungen an Datenhaltungs- und Dokumentationssysteme, die unbedingt erfüllt werden müssen (mandatory requirements). Diese werden in generelle Anforderungen und detaillierte Anforderungen unterteilt. 2. Nicht zwingend zu erfüllende Anforderungen (non mandatory features), die von den Aktivitäten zum Einkauf und des Betriebes als Nice-to-haveFeatures beschrieben werden oder sonstige Nice-to-have-Eigenschaften eines Datenhaltungs- und Dokumentenmanagementsystems darstellen. 3. Letztendlich werden die Anforderungen zum Management klassifizierter Dokumente und optionale Sicherheitsleistungen beschrieben. Die internationale Norm für Information and Documentation – Records Management ISO 15489 von 2001 beschreibt die Anforderungen des Department of Defense in allgemeiner Form.

104

3 Rechtliche Grundlagen des Information Lifecycle Management

C2.1. GENERAL REQUIREMENTS C2.1.1. Managing Records. RMAs shall manage records in accordance with this Standard, regardless of storage media or other characteristics. See 44 U.S.C. 3103 and 36 CFR 1222.10, references (p) and (q). C2.1.2. Accommodating Dates and Date Logic. RMAs shall correctly accommodate and process information that contains dates in current, previous, and future centuries. See FIPS 4-2, reference (r). The capability shall include, but not be limited to, century recognition, calculation, and logic that accommodates same century and multi-century formulas and date values, and date interface values that reflect the century. RMAs shall store years in a 4-digit format. Leap-year calculations shall be accommodated (e.g., 1900 is not a leap year; 2000 is a leap year). C2.1.3. Implementing Standard Data. RMAs shall allow for the implementation of standardized data in accordance with DoD 8320.1-M (reference (s)). When selecting commercial-off-the-shelf (COTS) products to support RMA requirements, selection criteria should include the feasibility and capability of the COTS products to implement and maintain DoD data standards. This requirement implies the capability for adding user-defined metadata fields and modifying existing field labels. C2.1.4. Backward Compatibility. RMAs shall provide the capability to access information from their superseded repositories and databases. This capability shall support at least one previously verified version of backward compatibility. C2.1.5. Accessibility. The available documentation for RMAs shall include product information that describes features that address 36 CFR parts 1194.21 and 1194.31 (references (t) and (u)). For web-based applications, 36 CFR part 1194.22 (reference (v)) shall also apply. See 29 U.S.C. 794d (reference (w)). Abb. 3.33. DoD 5015.2; Generelle Anforderungen an Datenhaltungssysteme94

3.5 Zertifikate, Prüfstellen und Standards Zertifikate zur Compliance werden heute nahezu für sämtliche dargestellten nationalen und internationalen Vorschriften erteilt. Die Zertifizierungen erfolgen durch unterschiedlichste Zertifizierungsorganisationen. Gemein ist jedoch allen Zertifikaten und Zertifizierungen, dass sie jeweils lediglich Teilaspekte begutachten. Es gibt kein Zertifikat, das ein Software- oder Hardwaresystem oder eine Infrastruktur als erfüllend für alle beschriebenen Vorschriften erklärt (Compliant).  94

DoD 5015.2-STD, "Design Criteria Standard for Electronic Records Management Software Applications," 06/19/2002, S. 24, verfügbar über: http://www.dtic.mil/whs/directives/corres/pdf/50152std_061902/p50152s.pdf.

3.6 Information als Produktionsfaktor und Produkt

105

So werden Produktzertifizierungen von Buchhaltungs-, Rechnungslegungsund Dokumentenmanagementsystemen (Soft- und Hardware) auf Compliance zu den Anforderungen des HGB, der GoB und der GoBS gemäß Prüfstandard PS 880 des IDW (Institut der Wirtschaftsprüfer) durchgeführt. Die zu dokumentierenden Verfahren werden durch Verfahrensprüfungen der jeweils überwachenden Behörden (z. B. BaFin, Bundesversicherungsamt, SEC) zertifiziert.

3.6 Information als Produktionsfaktor und Produkt sowie die relevanten juristischen Grundlagen Ein ILM-Konzept ohne Einbeziehung der Bedürfnisse der Unternehmenssteuerung ist nicht vollständig. Die Umsetzung von ILM-Konzepten in Unternehmen wird jedoch erst in der Zukunft erfolgen. Die meisten Unternehmen sind noch dabei, die Voraussetzungen für die Umsetzung eines Information Lifecycle Management zu schaffen. Die Konsolidierung der IT-Infrastruktur sowie die Virtualisierung der Dienste sind Projekte, die heute umgesetzt werden. In den entsprechenden Kundenprojekten der beiden Autoren hat sich erwiesen, dass es absolut sinnvoll ist, bereits heute über die Bewertungskriterien nachzudenken, um die Grundlagen für eine aktive Verwaltung der Unternehmensdaten über ihre ganze Lebenszeit hinweg zu schaffen. Ohne den Einbezug der Bedürfnisse der Unternehmenssteuerung sind die Kriterien nicht vollständig. Ein Information Lifecycle Management kann nur dann nachhaltig umgesetzt werden, wenn die Verwaltung der Business-Performance-Daten mit einbezogen wird. Betriebswirtschaftliches Management im Sinne des erfolgsorientierten Handelns legt nahe, Daten gemäß ihrem Lebenszyklus zu verwalten und zu speichern. Dieses Vorgehen aus rein ökonomischer Sicht wird durch die Regularien nationaler und internationaler (Rechts-) Vorschriften und Standards gestützt. Letztere regeln auch klar die Verantwortlichkeiten. Verantwortlich sind Managementrollen bzw. – da juristisch eine Rolle nicht belangt werden kann – die jeweils natürliche Person, die diese Rolle zu einem gegebenen Zeitpunkt wahrnimmt. Damit kann jeder Mitarbeiter, der eine verantwortliche Rolle in diesem Prozess wahrnimmt, auch gemäß § 611 BGB (Vertragstypische Pflichten beim Dienstvertrag) in die Pflicht genommen werden. Demnach wird durch den Dienstvertrag derjenige, der Dienste zusagt (Arbeitnehmer), zur Leistung der versprochenen Dienste, der andere Teil (Arbeitgeber) zur Gewährung der vereinbarten Vergütung verpflichtet. Eine Konkretisierung dieser gegenseitigen Verpflichtung erfolgt durch den Arbeitsvertrag, Arbeitsanweisungen und – soweit Regelungen fehlen – durch die „Verkehrssitte“. Als Haftungserleichterungen für die Haftung der Arbeitnehmer gegenüber dem Arbeitgeber gelten: x Die Stellung innerhalb der Hierarchie, x Der Sorgfaltsmaßstab zur Beurteilung von Pflichtverletzungen und x Die Gefahrgeneigtheit der Arbeit.

106

3 Rechtliche Grundlagen des Information Lifecycle Management

Diese Haftungserleichterungen bedeuten für das Vorliegen einer leichten Fahrlässigkeit des Arbeitnehmers, dass er nicht in Haftung genommen werden kann. Mittlere Fahrlässigkeit bewirkt eine anteilige Haftung, Vorsatz oder grobe Fahrlässigkeit bedeutet alleinige Haftung des Arbeitnehmers. Für diese gibt es eine Haftsummenbeschränkung aus der aktuellen Rechtsprechung (Bundesarbeitsgericht) in Höhe der nach Abzug des pfändungsfreien Einkommens verbleibenden Summe während der nächsten 5 bis 7 Jahre. Folgende ausgewählten Beispiele aus der IT-Praxis sollen die Bedeutung von § 611 BGB plastisch hervorheben. Die unzureichende Aktualisierung eines Datensicherungskonzeptes, bei der zwar ein Backup vorgesehen war, eine neu installierte Anwendung jedoch nicht korrekt eingebunden war, verstößt gegen die Verkehrssitte, dass eine regelmäßige Aktualisierung des Datensicherungskonzeptes zu erfolgen hat. Dieser Verstoß ist grob fahrlässig, der Mitarbeiter haftet grundsätzlich voll, eine Haftungserleichterung kommt nur bei einem Missverhältnis zwischen Schaden und Einkommen in Betracht.95 Die Verfügbarkeit und Geldauszahlungsfähigkeit eines Geldautomaten war für einen 24-Stundenbetrieb an 7 Tagen (7 u 24 Betrieb) zugesagt worden. Der für den Geldautomatenprozess eingesetzte Server war jedoch dafür nicht ausreichend abgesichert. Dieses Außerachtlassen bekannter Anforderungen an hohe Verfügbarkeitsstandards ist grob fahrlässig. Der Mitarbeiter haftet grundsätzlich voll, eine Haftungserleichterung kommt nur bei einem Missverhältnis zwischen Schaden und Einkommen in Betracht.96 Diese Fallbeispiele sollen als Anreiz dienen, einen genauen Umgang mit den Rechtsvorschriften zu pflegen. Dies bedeutet grundsätzlich folgendes Vorgehen für ein Unternehmen: 1. Exakte Identifikation der Anforderungen – Welche konkreten Rechtsvorschriften müssen erfüllt sein? Wer ist die korrekte Kontrollinstanz? Was wird hinsichtlich der Einhaltung der Rechtsvorschriften geprüft? 2. Enge Zusammenarbeit mit den Kontrollinstanzen – Aufbau einer Kommunikationsmatrix für die Kommunikation zwischen Fachabteilung, Management, internen Controllern und externen Prüfern. 3. Zuordnung der Anforderungen zu den eingesetzten Systemen Wird ein solches Vorgehen gewählt, so wird die gewählte Strategie zur Implementierung des Information Lifecycle Management sowohl kaufmännischen, als auch juristischen Anforderungen entsprechen. Wie ein Projekt zur Implementierung eines solchen Systems im Detail gestaltet werden muss, wird im Buch „Information Lifecycle Management – Prozessimplementierung“ auf Basis eigener, einschlägiger Erfahrungen dargestellt.

 95 96

Quelle: Clifford, Chance, Pünder, Rechtsanwälte, Frankfurt. Quelle: Clifford, Chance, Pünder, a.a.O.

4 Schlüsselfaktor ILM-Modell

ILM ist zuerst einmal konzeptionell unabhängig vom Geschäftsmodell. Trotzdem beeinflusst die Entscheidung zugunsten eines Information Lifecyle Management nachhaltig die Leitlinien für die unternehmerischen Entscheidungen und den Einsatz der Mittel über einen langen Zeitrahmen. Insbesondere vor dem Hintergrund der Langfristigkeit der ILM-Entscheidungen gilt es für das Management, die richtigen Antworten zu finden auf die zentralen Fragen: x Wie werden die Kundenbedürfnisse zukünftig aussehen? x Wie wird der Wettbewerb auf Veränderungen reagieren, wie Technologien sich entwickeln – wer kann darüber sichere Aussagen machen? x Was ist überhaupt möglich? In der Theorie beruhen weise Entscheidungen auf Wissen, Nachdenken und viel Zeit. In der Praxis jedoch sind Weisheit und Zeit ziemlich knappe Güter, weil Wissen oder Zeit zum Nachdenken fehlt. Der Grieche Perikles formulierte schon vor fast zweitausendfünfhundert Jahren: „Es kommt nicht darauf an, die Zukunft vorauszusagen, sondern auf sie vorbereitet zu sein.“97 Winston Churchill äußerste sich zum Thema Zukunftsvorhersage folgendermaßen: „Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen.“98 Also stellt sich die Frage: Gibt es eine Methode, die zuverlässig und trotzdem einfach genug ist, um unter großem Zeitdruck die richtigen Prioritäten zu setzen? Es gibt eine solche Methode. In vielen Situationen besteht die Möglichkeit, vorhandene typische Strukturen und Informationen auszunutzen. Beobachtet man die Vorgänge in verschiedenen Unternehmen, so lassen sich vereinfacht folgende Bereiche mit Handlungsbedarf lokalisieren: x x x x

Festlegung der IT-Strategie, Klärung der Anforderungs- bzw. Problembereiche, Klärung der technischen Erfordernisse, Interner Klärungsprozess von Angeboten und Begrifflichkeiten,



97 98

Perikles, Deutsche Nationalbibliothek, http//dispatch.opac.d-nb.de. Winston Churchill, Mark Twain, Karl Valentin, http://de.wikipedia.org/wiki/prognose.

108

4 Schlüsselfaktor ILM-Modell

x Evaluierung des Anbietermarktes, x Bewertungen unter Preis-/Leistungs-Gesichtspunkten. Denn es gilt: „Glück hat auf Dauer doch wohl meist nur der Tüchtige.“ 99

4.1 Die Bedeutung der Strategie „Strategie ist eines jener Wörter, die wir gern auf eine bestimmte Weise definieren, jedoch auf eine andere Weise verwenden.“100 Es gibt sehr viele Definitionen der Strategie. Für den einen ist sie ein Plan, für den anderen ein Muster, für den Dritten eine Art List. Das Wort Strategie stammt aus dem Griechischen. Es wurzelt in „strategos“, was so viel heißt wie Feldherr, und „agein“, gleichbedeutend mit „führen“. Etymologisch wird es definiert als „Plan für das Vorgehen“. Vor diesem Hintergrund wundert es nicht, dass Strategie als Konzept zuerst in militärischem Zusammenhang auftauchte – lange vor den Griechen zum Beispiel in China. Wer kennt nicht die 36 Strategien zum Sieg.101 Aber schon viel früher – am Anfang der Evolution – gab es bereits ein wesentliches Merkmal der Strategie, den Wettbewerb. Dies führte den Harvard-Professor Wilson zu der Erkenntnis, dass die Wirtschaft „ein Zweig der Biologie im weitesten Sinn“ ist.102 Die Strategie lässt sich auch als Weg zum Ziel verstehen: x Sie gibt Richtungen und Handlungsbahnen vor. x Sie bestimmt die Leitlinien für unternehmerische Entscheidungen und den Einsatz der Mittel. Ganz unabhängig aber von einzelnen Definitionen sind drei Arten von Strategien zu unterscheiden, die „beabsichtigten“, die realisiert werden, die „beabsichtigten“, die nicht realisiert werden, sowie die „nicht beabsichtigten“, die umgesetzt werden. Warum diese Unterscheidung? Ganz einfach, weil die Praxis zeigt, dass realisierte, erfolgreiche Strategien nicht immer beabsichtigt waren. Und dass – im Gegenzug – beabsichtigte Strategien nicht immer umgesetzt werden. Am häufigsten taucht in der Praxis die „nicht beabsichtigte“ Strategie auf. Die meisten Unternehmer setzen nicht alles um, was sie sich ursprünglich vorgenommen haben, weichen aber auch nicht allzusehr von der ursprünglichen Strategie ab. Diese Art von Strategie ist eine, die sich im Laufe der Zeit herausbildet (emergent strategy). Sie ist – allen Erfahrungen nach – die erfolgreichste. Leicht nachvollziehbar ist deshalb, dass sich in einem adaptiven Strategie-Typus beides trifft: x das kontrollierte Vorgehen und x die Offenheit für Lernerfahrungen, welche die Realität oft erfordert. 

99

100 101 102

Moltke, http://de.wikiquote.org/wiki/Gl/C3/BCck. Mintzberg, http://de wikipedia.org/wiki/Henry_Mintzberg. Sun Tsu, Sunzi, Die Kunst des Krieges, www.methode.de/bu/stb/tisunt1.htm. Wilson, http://en.wikipedia.org/wiki/Edward_Osborne_Wilson.

4.1 Die Bedeutung der Strategie

109

4.1.1 Herausforderung: Strategisches Handeln Exakte Planung bis ins Detail kann es nicht geben – dies gilt insbesondere für ILM – und ist auch gar nicht erstrebenswert. Wer aber deshalb strategisches Vordenken ignoriert, kommt ebenso in Bedrängnis. Erfolgversprechend dagegen erweist sich der Weg der geplanten Evolution und Adaption. Er erstreckt sich im Spannungsfeld von klar gesetzten Zielen und noch zu gewinnenden Erfahrungen. Für diesen Umgang mit der Realität ist ein konzeptionelles Raster erforderlich. Ein Filter, mit dessen Hilfe die Ereignisse und Entwicklungen gedeutet, bewertet und rationalisiert werden. Auf eine Strategie bezogen heißt das ein Muster von Handlungen, die aufeinander abgestimmt sind – und zwar dauerhaft und konsistent. Dabei gilt der Grundsatz, je mehr Unsicherheiten das Umfeld aufweist, desto wichtiger wird ein System, dem Unwägbaren zu begegnen. Anders gesagt, je unberechenbarer die Ereignisse im Wettbewerbsumfeld, desto wichtiger wird strategische Planung. Strategien spielen daher immer dort eine Rolle, wo es um komplexe Wettbewerbsverhältnisse geht. Nicht nur in Wirtschaft, Politik und Verteidigung, sondern auch beim Spiel. Welches Spiel liegt also der Strategie – als „Königsdisziplin“ des Managements – näher als Schach? Es gibt viele Parallelen: x Keine Strategie ohne Schachzüge. x Keine gewonnene Schachpartie ohne kluge Strategie. Schach stellt nicht nur in stilisierter Form alte Schlachtordnungen dar, sondern auch ein diffiziles Wettbewerbssystem. Die Konsequenz eines einzelnen Zuges ist nicht sofort erkennbar. Strategisch denken heißt, nach vorn zu schauen, Veränderungen in Markt und Wettbewerb zu antizipieren, Trends und Wachstumsfelder aufzuspüren. Dazu gehört insbesondere Mut. Eine – durchaus beabsichtigte – Folge davon sind strategische Entscheidungen, die Märkte bewegen können. Interessant auch, worauf der Erfolg von Schachcomputern beruht: x Mustererkennung und x Faustregeln. Zwei Fähigkeiten, die auch Bestandteile von Strategien im Wettbewerb sind. Dennoch gestalten sich diese ungleich komplizierter. Schließlich ist die Wirtschaft kein System, das sich auf 64 Feldern abspielt, sondern auf einem Terrain der ungezählten – und zum Teil unvorhersehbaren – Möglichkeiten. Dies gilt natürlich insbesondere für ILM, da hier die Entwicklung über mehrere Jahre antizipiert werden muss.

4.1.2 Herausforderung: Effizienz In herkömmlichen IT-Umgebungen sind Ressourcen wie Server oder Speichersysteme meist einzelnen Anwendungen oder einem bestimmten Geschäftsprozess fest zugeordnet. Um Belastungsspitzen abzudecken, sind die einzelnen Systeme in der Regel für den durchschnittlichen Betrieb deutlich überdimensioniert. So

110

4 Schlüsselfaktor ILM-Modell

laufen zum Beispiel Server meist mit nur einer durchschnittlichen Auslastung im unteren Prozentbereich. Falls dennoch ein System vorübergehend an seine Leistungsgrenzen stoßen sollte, können die zu diesem Zeitpunkt verfügbaren Ressourcen der anderen Komponenten nicht für diese Anwendung genutzt werden. Auch die Betriebsführung muss sich weiterentwickeln. Die Tendenz geht hier weg vom herkömmlichen Ressourcenmanagement hin zum Service- und Business-Management. Während das Ressourcenmanagement einen sicheren ITBetrieb gewährleistet und IT-Services sicherstellt, steuert das Servicemanagement die IT-Prioritäten durch SLAs und verbessert deren Qualität durch den Einsatz von ITIL-basierten „Best Practices“. Das Business-Management integriert auf Basis einer „Service orientierten Architektur“ (SOA) schließlich die IT vollständig mit den Geschäftsprozessen. So werden beispielsweise Abhängigkeiten zwischen Geschäftsprozessen und IT-Ressourcen abgebildet und bei Veränderungen in der IT die Auswirkungen auf das Geschäft analysiert. ILM-Lösungen bieten unbestreitbar eine Reihe an Nutzeneffekten. Damit diese zur Wirkung kommen, müssen allerdings sowohl die Rahmenbedingungen als auch die Vorstellungen ihres Einsatzes im Unternehmen stimmen.

4.1.3 Herausforderung: Reduzierung der Komplexität Die einfache Lösung ist manchmal die bessere. Dies gilt insbesondere für ILM. Konsolidierte und standardisierte Infrastrukturen erleichtern nicht nur die Virtualisierung. Unternehmen profitieren auch von einer einfacheren Administration. Anstatt mit zahlreichen unterschiedlichen Software-Tools die Insellösungen zu verwalten, können sie nun die gesamte IT unter einer Oberfläche administrieren. Das so genannte Unified Infrastructure Management führt dabei nicht nur die Verwaltung lediglich der Server oder nur der Speicherlösungen zusammen, sondern vereint beide in einer umfassenden Ansicht. Offene Schnittstellen erlauben darüber hinaus die Anbindung der Hardwareverwaltung an weiter reichende Managementlösungen. Die Schnittstellenproblematik sieht auf grafischen Darstellungen mit den gewachsenen Point-to-Point-Verbindungen zwischen allen vorhandenen Applikationen oftmals dramatisch aus. Hinzu kommen Berechnungsformeln, die allein auf der Anzahl der Applikationen beruhen. Nur in wenigen Fällen wird dabei der Hinweis angeführt, dass in der Praxis nur sehr selten jede Applikation mit allen anderen verbunden ist und auch nicht sein muss. Entsprechend lohnt sich in vielen Unternehmen ein genauer Blick auf die Schnittstellenlandschaft.

4.1.4 Herausforderung: IT-Strategie In der IT-Strategie wird in vielen Unternehmen auf gewohnte Konzepte gesetzt. Hierzu gehören die kurzfristige Umsetzung von fachlichen Anforderungen, erprobte programmiertechnische Methoden, produktorientierte Entscheidungen und Absicherung durch die Entscheidung für so genannte Marktführer. Zu selten werden für die gesamte IT gültige Modelle für eine einheitliche Systemarchitektur

4.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle

111

erarbeitet und konsequent umgesetzt. Dort, wo es versucht wird, bleibt der Ansatz oftmals bereits an der Oberfläche stecken, so dass konkrete Realisierungen die ursprünglichen Absichten unterlaufen. Im Umfeld von Überlegungen zur Einführung von ILM gehören jedoch grundsätzliche Erörterungen der IT-Infrastruktur, zukunftsweisende Systemarchitekturen mit entsprechenden Integrations- bzw. Ablösungsplänen der vorhandenen Plattformen und Applikationen sowie Richtlinien für zukünftige Anwendungsentwicklungen zwingend in eine allgemeingültige IT-Strategie. Grundlage einer Bewertung technischer Erfordernisse bilden die klassischen Größen Performanceanforderungen, Transaktionsvolumen, Komplexität der Datenflüsse und Geschäftsprozesse sowie Betriebs- und Backup-Zeiten. Die Gründe für einzelne Problemstellungen können dabei sehr unterschiedlich sein und Maßnahmen sind individuell zu entscheiden. Dabei bilden technische Reaktionen allein ohne begleitende organisatorische Maßnahmen nicht immer einen nachhaltigen Lösungsansatz. Organisatorische Maßnahmen sind nicht auf Änderungen von Prozessen beschränkt, sondern können z. B. auch das Datenmanagement von Dateien (Downloads aus dem Internet) betreffen. Weiterhin spielen insbesondere in Auswahlverfahren für Systemkomponenten sowie kompletter Systeme architektonische Strategien eine wesentliche Rolle. Je nach spezifischer Ausgangssituation lassen sich in Unternehmen regelmäßig die Bereiche Geschäftsprozesssteuerung, Datenflusssteuerung, Kommunikation und Schnittstellen herauskristallisieren. Häufig werden alle Bereiche als Anforderung in ein Projekt eingebracht.

4.1.5 Herausforderung: Erfolgreiches Projektmanagement Viele IT-Projekte in Unternehmen scheitern. Schuld daran ist oft das Topmanagement. Weil die Führungsriege nicht die Verantwortung für die wichtigsten ITEntscheidungen übernimmt, laufen die Vorhaben immer wieder ins Leere. Dies gilt insbesondere für ILM-Projekte mit den sich abzeichnenden langen Projektlaufzeiten, dem Einsatz der Mittel über einen langen Zeitraum und der Notwendigkeit, die Veränderungen im Markt und im Wettbewerb zu antizipieren, Trends und Wachstumsfelder aufzuspüren und mutig in eine Folge von strategischen Projektentscheidungen umzusetzen. Die besondere Schwierigkeit bei ILM-Projekten liegt in der relativ langen Laufzeit und der Notwendigkeit der Koordination verschiedener, quasiparalleler Projekte begründet.

4.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle Tagtäglich entsteht in Unternehmen eine regelrechte Flut unterschiedlicher Daten und Inhalte. Informationen sind dabei zu einem strategischen Vermögen

112

4 Schlüsselfaktor ILM-Modell

jedes Unternehmens geworden mit der Charakteristik, dass sie rasch zunehmen und ihr Wert sich im Laufe der Zeit verändert. Vor diesem Hintergrund bestehen beträchtliche Herausforderungen für das effektive Informations- und Speicher-Ressourcenmanagement. Vor allem E-Mails, aber auch Office-Dokumente und Anwendungsdaten erfordern immer größere Speicherkapazitäten. Gleichzeitig sollen die Unternehmen die Leistungsfähigkeit ihrer IT steigern und flexibel auf Marktveränderungen eingehen. Unternehmen sind deshalb gezwungen, eine flexible und ganzheitliche Betrachtung von ITInfrastruktur und der Verwaltung ihrer Daten zu entwickeln. Dies gilt insbesondere, da ILM selbst kein fertiges Produkt ist, sondern eine Infrastrukturlösung, die aus mehreren Komponenten besteht. Die BITKOM formulierte 2004 hierzu: ”ILM ist kein Produkt, sondern eine Kombination aus Prozessen und Technologien. Ziel ist es, die richtige Information zur richtigen Zeit am richtigen Ort bei geringsten Kosten zu haben. Dies wird in einem permanenten Optimierungsprozess erreicht. Der Optimierungsprozess erhält seine Parameter zum einen durch externe Vorgaben (Wert der Informationen, Sicherheitsanforderungen, Service Level Agreements etc.) und zum anderen durch die vorhandene Speicherhierarchie mit den darunter liegenden Kostenstrukturen.

Abb. 4.1. Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle103

 103

SNW Europe 2006, Frankfurt September 2006, Tagungsunterlage.

4.3 Strategische IT-Infrastrukturplanung

113

Als Ergebnis des Optimierungsprozesses ergeben sich Entscheidungen, wo Informationsobjekte am besten zu speichern sind bzw. wie Backup-, Replikations-, Verdrängungs-, Verlagerungs- und Archivierungsfunktionen zu steuern sind. Für ein effizient arbeitendes ILM sind gewisse Vorleistungen erforderlich. Virtualisierung für den Online-, Nearline- und NAS-Bereich sind Beispiele. Aufgrund der Trennung der logischen Sicht von der physikalischen Sicht wird ILM in die Lage versetzt, Informationsobjekte aufgrund der Prozessentscheidungen optimal zu platzieren.“104 Ein ILM-Konzept ohne Einbeziehung der Bedürfnisse der Unternehmenssteuerung und der Geschäftsprozesse ist nicht vollständig. Die Umsetzung von ILM-Konzepten in Unternehmen wird meist erst in der Zukunft erfolgen. Die meisten Unternehmen müssen im Vorfeld der ILM-Projekte erst die Voraussetzungen für die Umsetzung eines Information Lifecycle Management schaffen. Voraussetzung für die Einführung jedes ILM-Konzeptes ist eine offene ITStruktur mit einer hohen Datengranularität.

4.3 Strategische IT-Infrastrukturplanung 4.3.1 Herausforderungen für die Infrastrukturplanung In den Kontakten der beiden Autoren mit Chief Executive Officer (CEO), Chief Operating Officer (COO), Chief Financial Officer (CFO) oder anderen hochrangigen Managern beklagen diese Führungskräfte meist, dass die teure Technologie, die sie installiert haben, kaum echten betriebswirtschaftlichen Nutzen erzeugt. Gleichzeitig wächst die Liste der scheinbar unbedingt notwendigen technischen Erfordernisse, und die IT-Ausgaben verschlingen einen immer größeren Teil vom Budget. Tatsächlich zeigen die Untersuchungen der IT-Managementpraxis, dass die meisten nicht das Optimum aus ihren IT-Investitionen herausholen. Die Unternehmen, die ihre IT-Investitionen am erfolgreichsten managen, erwirtschaften deutlich höhere Erträge als ihre Wettbewerber. Es gibt eine Reihe von Faktoren, in denen sich diese erfolgreichen Unternehmen von anderen unterscheiden. Der wichtigste jedoch ist, dass die oberste Managementebene bei Schlüsselentscheidungen im IT-Bereich eine echte Führungsrolle einnimmt. Die Führungskräfte der weniger erfolgreichen Unternehmen erkannten nicht, dass die neuen Systeme nicht nur eine technische, sondern auch eine unternehmerische Herausforderung darstellten. Entsprechend übernahmen sie keine Verantwortung für die notwendigen Veränderungen der Organisation und der internen Prozesse. Die sechs zentralen IT-Entscheidungen des Managements sind: 1. Wie hoch soll das IT-Budget sein? 2. Welche Geschäftsprozesse stehen im Vorgrund? 

104

www.bitcom.org

114

3. 4. 5. 6.

4 Schlüsselfaktor ILM-Modell

Was wird IT-Standard? Welcher Service Level ist wirklich notwendig? Welcher IT-Schutz-Level ist notwendig? Wer hat die Verantwortung?

In den erfolgreichen Unternehmen wird zuerst die strategische Rolle der Informationstechnik für das Unternehmen im Rahmen der strategischen Planung festgelegt, erst dann bestimmen sie ein unternehmensweites Budget – eines, mit dem die festgelegten Ziele erreicht werden können. Die Ziele können entscheidend für die gesamte Unternehmensstrategie sein. Ausgangsbasis jeder strategischen Planung ist dabei die Analyse des Business-Requirement. Zum Beispiel ist die Aufrechterhaltung einer nahtlosen weltweiten Lieferkette oder eines reibungslosen Kundendienstes, aber auch die Unterstützung einer hoch entwickelten Forschungs- und Entwicklungsabteilung das vorrangige strategische Ziel. Solch unterschiedliche Ziele erfordern natürlich unterschiedliche Budgets. Und wenn die Informationstechnik eine zentrale strategische Rolle spielen soll, dann steigen damit die notwendigen Ausgaben. Nehmen wir als Beispiel die Erzrivalen United Parcel Service (UPS), FedEx und Deutsche Post World net. FedEx und UPS haben jährliche IT-Ausgaben von rund einer Milliarde Dollar. Die Deutsche Post World net hat mit der Deutsche

Abb. 4.2. Herausforderungen an das IT-Management105

 105

2

EMC Marketingunterlage 2005.

4.3 Strategische IT-Infrastrukturplanung

115

Post IT-Solution eine Entwicklungstruppe von ca. 1.300 Mitarbeitern. FedEx und Deutsche Post World net sind mit Jahreserlösen von knapp um die 20 Mrd. US$ nur etwa zwei Drittel so groß wie UPS. Heißt dies, dass die Informationstechnik bei FedEx und Deutsche Post eine größere Bedeutung hat bei sonst vergleichbaren Dienstleistungen? In allen drei Unternehmen weist die IT jeweils eine andere Ausrichtung auf. Die IT-Strategie von UPS hat ihre Wurzeln in dem Ziel einer Effizienzsteigerung, weil das Geschäftsmodell vor allem auf Stetigkeit und Verlässlichkeit basiert. Das zentralisierte und vereinheitlichte IT-Umfeld des Unternehmens erlaubt einen zuverlässigen Kundendienst zu relativ niedrigen Kosten. FedEx und Deutsche Post dagegen haben sich auf Flexibilität konzentriert, um den unterschiedlichen Erfordernissen ihrer verschiedenen Kundensegmente gerecht zu werden. Die höheren Kosten dieses dezentralen Ansatzes werden kompensiert durch die Vorteile lokaler Innovationen und die Fähigkeit, stärker auf individuelle Kundenwünsche einzugehen. Aktuell hat hier die Deutsche Post noch erhebliche Kostennachteile, die durch die neue Konzernstruktur reduziert werden sollen. In der Vergangenheit war bei der Deutschen Post IT-Solution ein erheblicher Aufwand notwendig, die Vielzahl von Applikationen, die von ihrer Architektur her veraltet, schlecht dokumentiert und unzureichend an die aktuellen Geschäftsprozesse angepasst waren, zu betreiben.

Abb. 4.3. Business Requirements106

 106

SNW, a.a.O.

116

4 Schlüsselfaktor ILM-Modell

Abb. 4.4. Die Balance zwischen Kosten und Nutzen

Entscheidungsträger erkennen zunehmend die erheblichen Einsparmöglichkeiten und strategischen Vorteile, die unternehmensweit zentralisierte ITLeistungen und eine standardisierte IT-Infrastruktur mit sich bringen. Dieser Ansatz macht die vorhandene technologische Expertise unternehmensweit nutzbar, erlaubt weit reichende und kostengünstige Verträge mit Softwareanbietern und erleichtert globale Geschäftsprozesse. Gleichzeitig können Standardisierungen aber die Beweglichkeit einzelner Geschäftsbereiche beschneiden und die Fähigkeit des Unternehmens beschränken, flexibel auf unterschiedliche Kundensegmente einzugehen. Und sie können den Widerstand der Geschäftsbereichsleiter herausfordern. Ein einheitliches Bild des Kunden zu bekommen, macht aber auch eine einheitliche Technologiebasis notwendig, die eine elektronische Kommunikation zwischen den einzelnen Regional- oder Geschäftsbereichen erlaubt. Managementteams in jedem Unternehmen, ob zentralisiert oder dezentralisiert, müssen bei der Verteilung von IT-Ressourcen und -Fähigkeiten kontinuierlich die Balance zwischen Gesamtunternehmen und einzelner Geschäftseinheit finden. Die Technik der Informationsverarbeitung und -speicherung hat sich in den letzten Jahren stark verändert. Die Frage der richtigen Architektur war dabei eine der zentralen Fragen. Ein EDV-System, das nicht den Anforderungen entspricht und nicht sicher funktioniert, ist für den betrieblichen Alltag nutzlos. Das bedeutet nicht, dass jedes IT-System den höchsten technischen Standards entsprechen muss. Es ist

4.3 Strategische IT-Infrastrukturplanung

117

Abb. 4.5. Die Veränderungen strategischer Fragestellungen

Aufgabe des Topmanagements zu entscheiden, wie viel Geld es für welche Funktionen und Services ausgeben will. Einige Unternehmen kommen an absoluter Spitzentechnik nicht vorbei. Die Trader einer Bank diskutieren gar nicht erst darüber, wie viele Daten bei einem Systemabsturz verloren gehen dürfen; eine 100-prozentige Datensicherung ist für sie eine existenzielle Notwendigkeit. Die meisten Firmen können jedoch mit gewissen Ausfallzeiten oder gelegentlichen Geschwindigkeitseinbußen leben. Sie müssen den daraus resultierenden Problemen die Kosten für deren komplette Vermeidung gegenüberstellen. Entscheidungen über die notwendige Leistungsfähigkeit der IT-Services müssen von hochrangigen Managern getroffen werden. Üblicherweise sind die Kosten für die höhere Leistungsfähigkeit in die Gesamtpreise der IT-Systeme eingerechnet und werden nicht extra ausgewiesen oder getrennt diskutiert. Die ITExperten sollten den Führungskräften deshalb mit einer Auswahl von Leistungen und Preisen erläutern, wofür sie welchen Geldbetrag ausgeben. Die Führungskräfte müssen dann in Absprache mit den IT-Fachleuten entscheiden, welches der richtige Leistungsumfang ist und zu welchem Preis dieser beschafft wird. Eine solche Analyse kann Auswirkungen nicht nur auf einmalige ITInvestitionen, sondern auch auf die jährlichen Betriebskosten haben. Gerade die sind in Unternehmen häufig ein umstrittenes Thema. In vielen Fällen können die Fixkosten während der Systementwicklung durch niedrigere Vorgaben für Systemstabilität und Geschwindigkeit erheblich reduziert werden. Umgekehrt

118

4 Schlüsselfaktor ILM-Modell

kann die Analyse auch zeigen, dass ein Unternehmen die Risiken von Ausfallzeiten unterschätzt hat und nicht ausreichend dagegen geschützt ist. Wie bei Zuverlässigkeit und Schnelligkeit gilt auch beim Thema Sicherheit, dass Unternehmen das gewünschte Ausmaß an Schutz mit ihren Vorstellungen über die Höhe der Investition abstimmen müssen. Höhere Sicherheit bedeutet nicht nur höhere Kosten, sondern auch eine geringere Nutzerfreundlichkeit. Dieses Abwägen ist die Aufgabe von Führungskräften. Erfolgreiche IT-Neuerungen brauchen manchmal auch die starke Unterstützung derer, die die Technik nutzen und von ihr profitieren sollen. Solange Manager keine Verantwortung für den Erfolg – und das Scheitern – von IT-Systemen übernehmen, werden diese Systeme vielleicht technisch elegant sein, sie werden aber keine realen Auswirkungen auf das Geschäft haben. Ein Unternehmen kann – je nach Kultur, Strategie und Struktur – zwischen unterschiedlichen Ansätzen wählen. Aber in jeder guten IT-Managementstruktur ist festgelegt, wer für die zentralen Entscheidungen verantwortlich ist und zur Rechenschaft gezogen werden kann. Das Unternehmen sollte sicherstellen, dass alle IT-Entscheidungen mit Blick auf die neue Strategie getroffen wurden. Das IT-Management kann eine Unternehmensführung überfordern. Es ist daher für viele Manager verlockend, diese Aufgabe einfach an einen Dritten abzugeben. Tatsächlich gab es eine Zeit, in der Outsourcing Managern als einfaches Mittel gegen die Frustrationen erschien und viele Unternehmen begannen, sämtliche IT-Funktionen von externen großen IT-Dienstleistern erfüllen zu lassen. Dies senkte die Kosten, und das Unternehmen ging Schwierigkeiten aus dem Weg, die eine eigene IT-Abteilung hätte mit sich bringen können. Aber das Outsourcing führte oft zu Unzufriedenheit im Unternehmen, besonders wenn die unternehmerischen Bedürfnisse sich veränderten. Der IT-Service der Dienstleister mit ihren standardisierten Angeboten und detaillierten Verträgen ist meist nicht darauf angelegt, auf veränderte Anforderungen einzugehen. Auch auf Probleme scheinen die Serviceanbieter oft nur sehr langsam zu reagieren. Wenn bei der Verhandlung des Supports für die unternehmenskritischen Mainframes keine klar definierten Reaktionszeiten und maximale Ausfallzeiten definiert werden, dann kommt zwar der Anwender ins Schwitzen, nicht aber der Servicepartner, wie die Autoren erst in jüngster Vergangenheit feststellen mussten. Darüber hinaus erfordert die Zusammenarbeit mit einem Zulieferer erhebliche Zeit- und Geldinvestitionen, wodurch dieser fest in die strategischen Planungen und betrieblichen Abläufe eingebunden werden muss. Das Unternehmen wird besonders dann verwundbar, wenn der Dienstleister seine vertraglichen Zusagen nicht einhalten kann. Weitere Probleme entstehen – nicht weiter verwunderlich – weil Führungskräfte mit dem Outsourcing der IT-Funktionen auch die Verantwortung für wichtige Entscheidungen auslagerten, die sie eigentlich selbst treffen müssen. Bei vier der sechs wichtigsten IT-Entscheidungen steht damit die Information entweder als Produktionsfaktor oder als Produkt im Mittelpunkt. Da ILM selbst kein fertiges Produkt, sondern eine Infrastrukturlösung darstellt, bestehend aus mehreren Komponenten, ist vor der Einführung jedes ILM-Konzeptes die Durchführung einer strategischen IT-Infrastrukturplanung zwingende Voraussetzung.

4.3 Strategische IT-Infrastrukturplanung

119

Abb. 4.6. Die Herausforderungen für den CIO bei der Strukturplanung

Die Entscheidungsträger definieren im Rahmen der strategischen Infrastrukturplanung entscheidend die Wettbewerbsfähigkeit ihres Unternehmens.

4.3.2 Die Ziele der strategischen IT-Planung Strategische Planung ist mehr als die intensive Lektüre einschlägiger Fachzeitschriften. Strategische Planung ist der informationsverarbeitende Prozess im Unternehmen zur Abstimmung von Anforderungen der Umwelt mit den Potenzialen des eigenen Unternehmens in der Absicht, durch Strategien den langfristigen Erfolg abzusichern. Es gibt wohl kaum ein Feld in der Betriebswirtschaftslehre und in der Informatik, auf dem Theorie und Praxis so Hand in Hand arbeiten wie bei der strategischen Planung. Denn diese Aufgabe verlangt dem Manager sowohl fundierte analytische Fähigkeiten als auch tatkräftiges Unternehmertum ab. Die Tätigkeiten eines Unternehmens konzentrieren sich heute mehr und mehr auf das Beschaffen, Verarbeiten und Speichern von Informationen. Diese sind, neben den eigentlichen Kernkompetenzen, zum wichtigsten Standbein avanciert. Damit geht eine enorme Anhäufung von Daten einher, da sich alles schlicht und einfach in den Tiefen irgendwelcher Speicherplatten aufbewahren lässt. Das stellt Unternehmen vor die Herausforderung, in zukunftsgeeignete ITInfrastrukturen zu investieren, die gleichzeitig signifikante Wettbewerbsvorteile schaffen.

120

4 Schlüsselfaktor ILM-Modell

Abb. 4.7. Die Wertschöpfung in Form einer Wertschöpfungskette gem. Porter

Der namhafte Experte Michael E. Porter formuliert zum Thema Wettbewerb: ”Competitive advantage grows out of the value a firm is able to create for its buyers that exceeds the firm´s cost of creating it. Value is what buyers are willing to pay, and superior value stems from offering lower prices than competitors for equivalent benefits or providing unique benefits that more than offset a higher price. There are two basic types of competitive advantage: cost leadership and differentiation.“ 107 Die Entwicklung der Information-Service-(IS-)Strategie ist letztendlich ein Auswahlproblem (welche IS realisieren?) und ein Konfigurationsproblem (wie stehen die einzelnen IS zueinander?). Auswahl und Konfiguration basieren auf einem möglichst breiten Verständnis der theoretisch realisierbaren IS. Ein zentraler Punkt jeder Strategie sind die Kosten. Die IT-Kosten besitzen eine spezifische Dynamik: ”Each dollar spent on systems development generates, on average, a follow-on annual cost of 40 cents for maintenance of the system and 20 cents for operations.  107

Porter, Michael E.: Competitive Advantages: Creating and Sustaining Superior Performance, NY, 1985, S 3.

4.3 Strategische IT-Infrastrukturplanung

121

Abb. 4.8. Kosteneinsparungspotenziale

Only about 10 % of an Information Services group´s staff resources are available for developing new systems. Half or more are tied up in maintaining existing ones. “ 108 Die meisten Unternehmen kennen leider weder ihre IT-Kosten noch ihre Kosteneinsparungspotenziale, da diese nicht vollständig durch die betrieblichen Rechnungswesensysteme erfasst werden. ”Accounting systems rarely track the real costs of IT, most of which are hidden. A useful rule of thumb is that the visible price of any IT investment is only 2025 % of the full cost. “ 109 Ein wesentlicher Kostentreiber im Betrieb von IT-Infrastruktur ist die Heterogenität der Hardware mit einer Vielzahl unterschiedlicher Versionsstände und Prozessoren. Der Markt für IT-Plattformen ist deshalb in den letzten Jahren in Bewegung gekommen. Neben Windows und mehreren Linux-Varianten stehen Novell Open Enterprise Server als Netware-Nachfolger, SUN Solaris, IBM AIX oder HP-UX zur Wahl. Jedes dieser Angebote hat dabei das eine oder andere Feature, das jedoch bei der Auswahl nur eine singuläre Rolle spielen darf. Bei 

108 109

Blecher, Michael, Gartner Group: Component based Development: The next wave, 4/1999. Blecher, Michael, a.a.O.

122

4 Schlüsselfaktor ILM-Modell

Abb. 4.9. Kosteneinsparungspotenzial einzelner Maßnahmen110

der Entscheidung für eine IT-Plattform sind folgende Punkte von elementarer Bedeutung: x x x x x

Erzielt eine Open-Source-Plattform einen langfristigen Kostenvorteil? Welche Plattform bietet die sicherste Computerumgebung? Ist eine Interoperabilität gegeben? Welche Alternativen bieten sich bei der Umstellung oder Migration? Steht eine IT-Infrastruktur-Management-Umgebung zur Verfügung?

Insbesondere das zentrale Management der verteilten IT-Infrastruktur ist eine Anforderung im Hinblick auf einen sicheren und wirtschaftlichen Betrieb. An eine Lösung, die für die Überwachung auf Betriebssystem- und Applikationsebene eingesetzt wird, muss die folgende Anforderung gestellt werden: x Zentralisierte Lösung, d. h., von einer Konsole können sämtliche Systeme überwacht werden. x Zentrales Einsammeln der Event-Logs der Server und möglichst auch der Speichersysteme. x Regelbasierte Interpretation der Einträge, da sonst die Vielzahl der Events die Administratoren überfordert. 

110

2

Quelle EMC ; Marketingunterlage.

4.3 Strategische IT-Infrastrukturplanung

123

Abb. 4.10. Einsatz der Speichermedien hinsichtlich der spezifischen Eigenschaften

Im Zusammenhang mit der Vielzahl der Tools sind auch die Ausbildungskosten zu sehen, deren Budget meist im Personalbereich verwaltet wird, und deren sinnvolle Höhe von oftmals bis zu 20 Prozent der Kosten eines Projekts bei der Projekt-Budget-Planung nicht berücksichtigt werden. Meist wird zudem unterschätzt, dass insbesondere während der Projektlaufzeit die beteiligten Angestellten keine Zeit haben, die für sie zwingend notwendigen Schulungen neben ihren eigentlichen Aufgaben, den spezifischen Projekterfordernissen und den persönlich genutzten Zeiten wahrzunehmen. Ein weiteres großes Problem vieler Unternehmen ist die Vielzahl der parallelen Projekte. Wir kennen Unternehmen mit ein paar hundert Mitarbeitern, die an mehreren hundert Projekten zugleich arbeiten. Natürlich sind nicht alle gleich wichtig. Aber wir stellen fest, dass Führungskräfte eine Scheu haben, einzuschreiten und eine klare Auswahl zu treffen zwischen Projekten mit erheblichen Auswirkungen auf den Geschäftserfolg und solchen, die zwar auch bestimmte Vorteile bringen, aber letztlich nicht lebenswichtig sind. Wird der IT-Einsatz aus einem rein technischen Blickwinkel bestimmt, können sich weit reichende Folgen ergeben. Die Wichtigkeit dieser auf den ersten Blick noch sehr generischen Aussage zeigt das Beispiel „Schaffung von Wettbewerbsvorteilen durch Wachstum“ und die operative Umsetzung der Wachstumsstrategie durch M&A-Projekte. Ein Unternehmen kann nicht aus eigner Kraftanstrengung die angestrebten Wachstumsziele erreichen und nutzt das Instrument Unternehmenskäufe/Fusionen. Es muss daher zwingend die IT-InfrastrukturArchitektur und die Informations-Servicesstrategie so wählen, dass sowohl mög-

124

4 Schlüsselfaktor ILM-Modell

lichst viele potenzielle M&A-Kandidaten integriert werden können als auch M&A möglichst rasch und kostengünstig vollzogen werden können. Die Bedeutung der strategischen Planung, der strategischen IT-Infrastrukturund -Service-Planung und deren Interaktionen vor dem Blickwinkel Einführung von ILM würde es eigentlich erforderlich machen, hierzu ein eigenes Buch zu schreiben. Die Begrenzung des Buchumfangs macht es notwendig, nur die wichtigsten Punkte verkürzt darzustellen. Nachfolgend stellen wir ein Analyseraster vor, auf dessen Basis eine Vielzahl verschiedener IS-Typen klassifiziert werden kann. x Information-System-Strategie Die Teilstrategie der Unternehmensstrategie, die den langfristigen Handlungsspielraum für den unternehmensweiten Einsatz von IT festlegt mit dem Ziel, insbesondere die unternehmenskritischen Geschäftsprozesse zu unterstützen. x Information-Service-(IS-) Strategie Die Teilstrategie der Informatik-Strategie, die bestimmt, welcher Grad an Information Service zur Erreichung der Unternehmensziele realisiert wird. x Information-Technology-(IT-) Strategie Die Teilstrategie der Informatik-Strategie, die den technologischen Handlungsrahmen festlegt, mit dem und in dem die in der Information SystemStrategie festgelegten IS realisiert und betrieben werden. x Information-Management-(IM-) Strategie Die Teilstrategie der Informatik-Strategie, die die Ausgestaltung des Führungskonzepts des Informationsmanagements festlegt. Strategische Information-System-Planung bedeutet in dem beschriebenen Kontext: x x x x x

Systematisches Vorgehen bei der Planaufstellung, Unternehmensweite, integrative Sicht, Management- und Benutzerperspektive, Planungshorizont von 5  10 Jahren und Jährliche Planwerte dokumentiert und akzeptiert. Die kritischen Erfolgsfaktoren jeder Strategie sind:

x x x x x

Schneller Ablauf von Geschäftsprozessen (“time to market”), Flexible Anpassung von Produkten an individuelle Kundenbedürfnisse, Hohe Qualität und exzellenter Service, Preis- oder Kostenvorteile gegenüber Mitbewerbern und Hohe Kompetenz und hohe Motivation auf allen Gebieten.

In Anlehnung an den Strategic Grid von Cash & McFarlan kann die ISStrategie auch nach der strategischen Bedeutung der IS gegliedert werden. Die entstehende Matrix besitzt Ähnlichkeiten zur bereits vorgestellten Produktportfolio-Matrix der Boston Consulting Group. Die um die Achse Produkte ergänzte Matrix-Betrachtung generiert normative Aussagen zur Ressourcenallokation und zum Service.

4.3 Strategische IT-Infrastrukturplanung

Abb. 4.11. Strategische Bedeutung der IT-Innovation

Abb. 4.12. Lösungsmodell ”Tiered“-Infrastruktur

125

126

4 Schlüsselfaktor ILM-Modell

Wichtige Gestaltungsbereiche der Hardwarearchitektur: x x x x

Hardwarekonfiguration und geografische Verteilung der Hardware, Festlegung von Kompatibilitätsregeln (Schnittstellenfunktion), Betriebssysteme und Hardware- und Lieferantenauswahl. Wichtige Gestaltungsbereiche der Kommunikationsarchitektur:

x Festlegung der Kommunikationswege und Netzwerktopologien für die unternehmensinterne und -externe Kommunikation und Integration, x Sicherstellung von Interlinking, x Sicherstellung von Interworking und x Festlegung geeigneter Kommunikationsstandards. Wichtige Gestaltungsbereiche der Datenarchitektur: x x x x

Design und geografische Verteilung zentraler Datenbanken, Datenmodell (Entitäten / Attribute) / Funktionenmodell, Standards und Protokolle für den Datenaustausch und Sicherheitsaspekte. Wichtige Gestaltungsbereiche der Applikationsarchitektur:

x x x x x x

Schnittstellen zwischen geplanten und bestehenden Systemen, Integrationsgrad der verschiedenen IS, Gemeinsame Module, IS-Entwicklungsmethodik und Standards z. B. für Programmierung und Test, Entwicklungssequenz der einzelnen IS und Einsatz und Integration von Standardsoftware (z. B. SAP R/3). Strategisches Informationsmanagement ist notwendig, da:

x IT sich für die meisten Unternehmen zu einem bedeutenden und stark wachsenden Kostenblock entwickelt hat; x IT in den meisten Unternehmen für die operative Tätigkeit unabdingbar geworden ist; x IT Wettbewerbsvorteile schaffen kann; x IT mikro- und makroökonomische Veränderungsprozesse verursacht oder verstärkt; x IT in allen Unternehmensbereichen eingesetzt werden kann; x IT neuartige IS ermöglicht; x der Einsatz von IT viele Stakeholders involviert; x ein rein technischer Blickwinkel den Beitrag der IT zum Unternehmenserfolg nicht sichert. Ziel der strategischen Planung ist eine effiziente und leistungsfähige ITInfrastruktur. Dieser Wunschtraum vieler CIOs ist aktuell meist schon durch Konsolidierung und Virtualisierung erreichbar.

4.3 Strategische IT-Infrastrukturplanung

127

Eine gute Basis für die Steigerung der Effizienz ihrer IT legen Firmen, wenn sie im ersten Schritt ihre Infrastruktur – von den Servern über die Speichersysteme bis hin zum Netzwerk – standardisieren und konsolidieren. Laut McKinsey lassen sich bereits durch die Standardisierung und Konsolidierung von Hardware und Diensten mindestens 20 Prozent der Kosten für den Betrieb und die Administration der IT-Umgebung einsparen. Konsolidierte und standardisierte Infrastrukturen erleichtern nicht nur die Virtualisierung. Unternehmen profitieren auch von einer einfacheren Administration. Anstatt mit zahlreichen unterschiedlichen Software-Tools die Insellösungen zu verwalten, können sie nun die gesamte IT unter einer Oberfläche administrieren. Das so genannte Unified Infrastructure Management führt dabei nicht nur die Verwaltung lediglich der Server oder nur der Speicherlösungen zusammen, sondern vereint beide in einer umfassenden Ansicht. Offene Schnittstellen erlauben darüber hinaus die Anbindung der Hardwareverwaltung an weiter reichende Managementlösungen. Die Konsolidierung und Standardisierung ihrer Infrastrukturen eröffnet vielen Betrieben einen bislang nicht erreichbaren Grad an Virtualisierung und somit den leistungsfähigeren Betrieb ihrer IT. Generell geht der Blick der IT-Verantwortlichen weg von der isolierten Betrachtung der Infrastruktur hin zu einem Management der gesamten IT-gestützten Unternehmensabläufe. Die Konsolidierung der IT-Infrastruktur sowie die Virtualisierung der Dienste sind Projekte, die bereits heute umgesetzt werden können und gleichzeitig bei intelligenter Herangehensweise die Basis für eine Einführung eines effizienten und leistungsfähigen ILM-Konzeptes schaffen können. Das Zusammenführen von heterogenen Systemen und so genannten Insellösungen zu einer einheitlichen und vereinfachten Infrastruktur senkt jedoch nicht nur die Kosten, sondern sorgt zusätzlich auch für eine höhere Ausfallsicherheit und senkt damit zusätzlich die Kosten des Betriebes. Der Einsatz von Komponenten, die auf Industriestandards basieren, gewährleistet darüber hinaus eine umfassende Skalierbarkeit. Ein weiterer Vorteil ist eine einheitliche und einfachere Verwaltung der gesamten Infrastruktur. Vor der Einführung einer ILM-Lösung sollten daher alle Konsolidierungspotenziale ausgeschöpft werden. Konsolidierung in Verbindung mit Standardisierung dürfte die Schlüsseltechnologie sein, um zum einen vernünftig zusammenhängende Speicherhierarchien zu schaffen und zum anderen die Anzahl der Speicherklassen in einem vernünftigen Umfang zu halten. Praxisbeispiele für effektive Konsolidierungen sind aus dem E-Mail-Bereich bekannt. Bei ILM in dezentralisierten Modellen ist der Kommunikations- und Administrationsaufwand um ein Vielfaches höher. So lassen sich mit entsprechenden Produkten mehrere hundert E-Mail-Server auf wenige Server konzentrieren. Der Anschluss einer Verdrängungs- bzw. Archivierungsebene ist bei wenigen Servern wesentlich einfacher zu realisieren als bei einigen hundert möglicherweise weit verteilten Servern. Die Virtualisierung ist im Unix-Bereich eine schon seit Jahren bewährte Technologie, wie z. B. in IBM AIX. Connectrix brachte 1997 eine erste Version der Software Virtual PC für Apple Macintosh auf den Markt. Ein Highlight des Pro-

128

4 Schlüsselfaktor ILM-Modell

Abb. 4.13. Einsparungspotenzial durch Konsolidierung111

duktes war die Unterstützung von OS/2 als dem Basisbetriebssystem. VMware hat in 1999 mit VMware das erste Produkt auf den Markt gebracht, das auf IntelWirt-Systemen den Betrieb einer virtuellen Umgebung erlaubte. Aktuell wird häufig zwischen drei Ebenen der Virtualisierung unterschieden: x der Element-Virtualisierung, x der integrierten Virtualisierung und x der vollständigen Virtualisierung der IT (Complete IT-Utility). Dabei gilt die Faustregel: Je höher der Grad der Virtualisierung ist, desto mehr geschäftliche Vorteile ergeben sich für das Unternehmen. Die Element-Virtualisierung bezieht sich auf einzelne Komponenten wie Server oder Speichersysteme oder auf Gruppen gleicher Geräte. Mit Lösungen für eine integrierte Virtualisierung gehen Virtualisierungskonzepte über die reine Geräteebene hinaus und sind auf die Optimierung von ganzen IT-Infrastrukturen für Anwendungsumgebungen und Geschäftsprozesse abgestimmt. Die integrierte Virtualisierung befähigt zum Beispiel Unternehmen, Service Level Agreements (SLA) automatisch einzuhalten. Anbieter von Virtualisierungslösungen arbeiten bereits an der vollständigen IT-Virtualisierung (Complete ITUtility). Im Rechenzentrum der nächsten Generation stehen dadurch alle heterogenen Ressourcen in Echtzeit zur Verfügung. Eine solche Infrastruktur zeichnet 

111

2

EMC , a.a.O.

4.3 Strategische IT-Infrastrukturplanung

129

Abb. 4.14. Virtualisierungsmodell

sich durch einen hohen Servicegrad und maximale Flexibilität aus. Ressourcen werden als Service bezogen und je nach Verbrauch bezahlt. Aktuell müssen die meisten Unternehmen im Vorfeld der ILM-Projekte erst noch die Voraussetzungen für die Umsetzung eines Information Lifecycle Management schaffen. Als sich vor einigen Jahren die Unzufriedenheit der Anwender von Fileservern hauptsächlich in Bezug auf Stabilität, Verfügbarkeit und Skalierbarkeit häufte, kamen die ersten Ansätze von dedizierten Fileservern unter dem Namen „Network Attached Storage“ (NAS) auf den Markt. Zunächst wurden nur im Marktsegment für das NFS-Protokoll entsprechende Systeme entwickelt, die sich nur um die Kernaufgabe des Fileservice kümmern sollten. Alle zusätzlichen Dienste oder gar Anwendungen wurden von dieser Plattform verbannt, um insbesondere dem Ziel der Stabilität näher zu kommen, als dies damals mit den bis dato bekannten Systemen möglich war. Der damit entstandene Appliance-Gedanke, der bereits im Bereich der Netzwerkinfrastruktur mit dedizierten Routern erfolgreich umgesetzt worden war, wurde damit konsequent auch für den Fileservice weiter gedacht. Auch vor dem Hintergrund der späteren Kundenwünsche und der weiteren technischen Entwicklung ist dieser Urgedanke mehr oder weniger in den heutigen Produkten wieder zu finden. Dabei kann heute im Wesentlichen die Trennlinie bei folgenden Merkmalen gezogen werden: „All-in-One“-Lösungen – Hier werden sämtliche Funktionalitäten über eine einzige zentrale Komponente im Netz zugänglich gemacht. Sämtliche Anforde-

130

4 Schlüsselfaktor ILM-Modell

rungen sind dabei über die gemeinsame Hard- und Software abzudecken. Integration von Fileservices und blockorientiertem Zugriff mit Bearbeitung der verschiedenen Protokolle bis herunter zur Speicherverwaltung und Überwachung des Gesamtsystems müssen in solchen Lösungen abgedeckt werden. Hieraus ergeben sich die folgenden Vor- und Nachteile: x (+) Gemeinsames Management von File- und Blockzugriff. x (-) Hohe Belastung des Gesamtsystems, da alle Zugriffe über die gemeinsame CPU bearbeitet werden müssen (macht das Loadbalancing erforderlich). x (-) Kaum skalierbar, da der Flaschenhals bei der zentralen CPU liegt. „Distributed“ Lösungen – In diesem Konzept wird die Fileserver-Funktionalität vom Speicher getrennt. Der NAS wird hier, genau wie andere offene Hosts (Unix, Linux, Windows etc.), an ein intelligentes Speichersubsystem angeschlossen. Funktional wird damit File- und Blockzugriff auf unterschiedliche Systeme verteilt, die damit auch für diese speziellen Aufgaben optimiert werden können. x (+) Trennen der Arbeitslast zwischen file- und blockorientierten Zugriffen. x (+) Damit bessere Skalierbarkeit durch eigenständige Prozessoren und für die benötigte Funktion optimierte Betriebssysteme. x (-) Externes Speichermanagement – jedoch mit Integration der Konfiguration der externen Komponenten (SAN-Switch etc.). Beide Ansätze unterscheiden sich meist auch in der Art, in der Hochverfügbarkeit erreicht werden kann. Hier gibt es zum einen das Clusterverfahren, bei dem sich die Systemkomponenten untereinander über den jeweiligen Status austauschen müssen, oder den Einsatz von Standby-Komponenten, die den Ausfall von Hardware kompensieren können. Als wesentliches Eckdatum beim Einsatz von Clustern ist die Anzahl der Knoten, die ein Cluster bilden kann, zu nennen. Bei maximal zwei Knoten zeigt sich recht schnell die eingeschränkte Skalierbarkeit des Gesamtsystems. Notwendige Erweiterungen können dann nur mit weiteren Systemen, die als separat zu administrierende Einheiten eingebunden werden müssen, realisiert werden. Insbesondere dann, wenn auch räumliche Trennung erforderlich ist, geht das nur zu Lasten des lokalen Schutzes der Lösung. Ein Ausfall eines Clusterknotens hat immer eine Reduktion der Performance des Gesamtsystems zur Folge (gilt nur für einen Aktiv-Aktiv-Cluster) die verbleibenden Knoten müssen die Aufgabe des ausgefallenen Knotens übernehmen. Das Standby-Verfahren kann aufgrund des n:1-Verfahrens auch eine größere Anzahl von NAS-Knoten absichern. Durch die Bildung von Failovergruppen kann flexibel auf die jeweils abzudeckenden SLA reagiert werden. Nach einem Failover steht bei diesem Verfahren aufgrund identischer Hardware die gleiche Leistungsfähigkeit des Gesamtsystems zur Verfügung wie vor dem Failover. Bei der Entscheidung für eines der vorgenannten Verfahren wird dann meist auch über das mögliche Administrationskonzept entschieden. Bei den Clustersystemen wird meist jeder Knoten separat administriert, oder aber es müssen bestimmte clusterrelevante Konfigurationen an allen beteiligten Knoten wiederholt werden. Nicht so beim Einsatz von Standby-Verfahren. Nach dem Stand

4.3 Strategische IT-Infrastrukturplanung

131

der heutigen Technik werden hier mehrere Knoten in einem System zusammengefasst, die dann auch als eine Einheit zentral administriert werden können. Die Überwachung erfolgt dazu meist von einer dedizierten Einheit in der NAS-Lösung, die aus Hochverfügbarkeitsgründen selbstverständlich auch redundant ausgelegt werden kann. Neben dem zentralen Management kann von hier auch ein automatischer Serviceruf an den Hersteller erfolgen, womit der Austausch defekter Komponenten ohne zusätzliche Einbeziehung des Kunden veranlasst werden kann. Neben diesen etwas ausführlicher erläuterten Punkten sind nachfolgende Aspekte insbesondere dann von entscheidender Bedeutung, wenn eine Integration in ein Windows-Umfeld geplant ist: x Welche Werkzeuge werden für die Integration der NAS-Lösung in das Microsoft Management Framework angeboten (z. B. MMC)? x Wie tief ist die Interoperabilität in der aktuellen Version der NAS-Software in das Microsoft-Betriebssystem vorangetrieben (Unterstützung von Event-Log, W2K3 – SMB packet signing, GPOs, Kerberos über TCP, etc.)? x Wie ist die Kooperation mit Microsoft, um zukünftige Anpassungen (Patches/Betriebssystemversionen) in die eigene NAS-Software einfließen lassen zu können? Auch wenn oberflächlich gesehen in den verschiedenen Lösungen die gleichen Funktionalitäten angeboten werden, lohnt es sich meist, die Details etwas näher zu betrachten. Ein Storage Area Network (SAN) basiert auf der Direktanbindung (Point-toPoint) zwischen Server und Speicher nach dem „Direct-Attached-Modell“, wobei ein separates Netzwerk aus Speicher-„Devices“ erstellt wird. Beim Netzwerk kann es sich um ein Fibre-Channel- oder Gigabit-Ethernet-Netzwerk (iSCSI, FCIP, iFCP) handeln. Ein SAN kann Festplatten und Bandspeichergeräte umfassen und vielen Servern zur Verfügung gestellt werden. Die Aufgabe von SAN ist es Daten zu übertragen, ohne dass sich dies auf die Auslastung des Kommunikationsnetzwerks auswirkt, denn die zur Verfügung stehende Bandbreite wird von den einzelnen Komponenten nicht geteilt, sondern ist dediziert zugeordnet. Das SAN ist für Netzwerkbenutzer transparent. Typische Anwendungen in einem SAN sind OLTP, Data Warehousing und ERP. Den Datenzugriff bezeichnet man als blockorientiert. Content Addressed Storage (CAS) basiert auf dem IP-Protoll. Kern des CASKonzeptes ist die Arbeit auf Basis von Objekten mit festem Inhalt und nicht mit Datenblöcken oder Dateien. Die speziellen Anforderungen an CAS liegen im Bereich der Langlebigkeit der Daten und der Sicherstellung deren Integrität. SAN-Technologien bieten Vorteile für geschäftliche und technische Anwendungen, deren Transaktionen eine optimale Performance erfordern sowie eine große Anzahl von Usern und große Datenbanken integrieren. In einem SAN kann der Speicher auf einfache Weise mit höherer Übertragungsrate und Flexibilität gespiegelt werden. Fibre-Channel-SAN decken große Entfernungen ab und ermöglichen die Adressierung von Millionen von „Devi-

132

4 Schlüsselfaktor ILM-Modell

Abb. 4.15. Die Speichernetzwerk-Virtualisierung

ces“. Dadurch werden die Verwaltbarkeit und die Flexibilität der Geschäftsumgebung durch ein zentrales Management von hunderten „Devices“ verbessert. Im Rahmen der Konsolidierung gewinnen Management und Sicherheit an Bedeutung. Auf SAN-Basis erstellte Software bietet Verbesserungen, die das Management von Datenmengen im Terabyte-Bereich ermöglichen. SAN-Infrastrukturen bieten flexibelste Speichermöglichkeiten, weit reichende Interoperabilität und umfassende Datenmigrations- und Verfügbarkeitsoptionen. Ein SAN bietet auch Volume-Replikationsmöglichkeiten, die Backup- und Disaster-Recovery-Lösungen vereinfachen. Durch Konsolidierung, verbesserte Anwendungsperformance und gesteigerte Skalierbarkeit optimieren SAN-Lösungen die Gesamtkosten (TCO). Unnötiges Duplizieren und Synchronisieren von Datenbeständen wird vermieden. Durch eine SAN-Lösung wird ein Lastausgleich für Server- und Speichersysteme und eine optimale Performance mit besseren Reaktionszeiten für die Anwendungen erreicht. SAN bietet die folgenden geschäftlichen Vorteile: x Niedrigere Kosten: Netzwerkspeicher verbessern die Speicherauslastung durch Konsolidierung. x Speicherkonsolidierung: Wenn alle Server einen gemeinsamen Speicherpool verwenden, steigt die Auslastung deutlich, und die Speichergesamtkapazität, die angeschafft und verwaltet werden muss, sinkt. x Serverkonsolidierung: Es müssen nicht mehr Server angeschafft werden, um die Zahl der Festplatten zu erhöhen – dafür sorgt das SAN.

4.3 Strategische IT-Infrastrukturplanung

133

x Konsolidierung des Personals: Weniger Server und weniger Speicher vereinfachen das Management. Die Verwaltung ist weniger komplex, so dass die Mitarbeiter mehr Zeit für unternehmenskritische Aufgaben haben. x Business Continuity: Reduziert das Risiko, das viele Backup-„Devices“ und viele Backup-Kontrollpunkte mit sich bringen. Ermöglicht Disaster-Recovery und Business Continuity als Nebeneffekt der Speicherkonsolidierung. Daten können konsolidiert verwaltet, kontrolliert und synchronisiert werden. Dies verbessert den Schutz der Informationen und gewährleistet die Informationssicherheit sowohl lokal als auch über große Entfernungen. x Geschäftliche Flexibilität: Besseres Wachstums- und Change-Management für neue und vorhandene Anwendungen, da mehr Personen, Anwendungen, Server und Speicher in einer Infrastruktur zusammengefasst sind. Dies erleichtert das Hinzufügen oder Erweitern gemeinsamer Funktionen auf mehr Komponenten und für mehr Benutzer. Eine einzige, konsolidierte Infrastruktur wird bereitgestellt, die den Informationsfluss beschleunigt, indem die Schranken zwischen unterschiedlichen Technologien und veralteten Infrastrukturen beseitigt werden, und der Informationsfluss zu mehr Menschen mit weniger Unterbrechungen beschleunigt wird. x Erleichtert die Erfüllung bestehender SLA mit bewährten Lösungen für hohe Verfügbarkeit und bietet die Flexibilität, neue SLA schnell und problemlos umzusetzen.

Abb. 4.16. Speichervirtualisierung

134

4 Schlüsselfaktor ILM-Modell

x Verwaltbarkeit: Zentralisiert das Speichermanagement und automatisiert die „Device“-Steuerung sowie die Ausführung von Aufgaben und Prozeduren in heterogenen Umgebungen. Führt leistungsfähigere Management-Tools und Automatisierung zusammen, die das Speichermanagement vereinfachen und weniger arbeitsintensiv machen. Dies ist ein wichtiger Schritt in Richtung effizientes Management mit einem halben Petabyte oder mehr pro Speicheradministrator. Intelligente Speichernetzwerke, wie Storage Area Networks (SAN), Network Attached Storage (NAS) und IP Storage, erleichtern die operative Umsetzung der dynamischen ILM-Entscheidungen erheblich. In intelligenten Speichernetzwerken hat im Prinzip jeder Server auf jeden Speicherbereich Zugriff. Dies schafft z. B. die Voraussetzung, um bei einer Erstzuweisung die bestgeeignete Speicherklasse auszuwählen. ILM ist zuerst einmal konzeptionell unabhängig von der Frage, ob die ITKonfiguration in einem dezentralisierten oder zentralisierten Modell betrieben wird, solange Kommunikationspfade zu den dezentralen Standorten bestehen. Im dezentralisierten Modell ist aber der Kommunikations- und Administrationsaufwand um ein Vielfaches höher. Vor der Einführung eines ILM müssen deshalb zuerst alle Konsolidierungspotenziale ausgeschöpft werden. Konsolidierung in Verbindung mit Virtualisierung dürfte die Schlüsseltechnologie sein, um zu einer unter wirtschaftlichen Gesichtspunkten vernünftigen, zusammenhän-

Abb. 4.17. Virtualisierung über die gesamte Infrastruktur

4.3 Strategische IT-Infrastrukturplanung

135

Abb. 4.18. Virtualisierung erfordert einen Multilevel-Ansatz

genden Speicherhierarchie zu gelangen und zum anderen die Anzahl der Speicherklassen in einem operativ handhabbaren Umfang zu halten. So lassen sich mit entsprechenden Produkten mehrere hundert E-Mail-Server auf wenige Server konzentrieren. Der Anschluss an Speicherhierarchien nach einer Verdrängungs- bzw. Archivierungsebene ist bei wenigen Servern wesentlich einfacher zu realisieren, als dies bei einer Vielzahl meist auch noch räumlich weit verteilter Server möglich ist. Ein effektives ILM setzt einen einfachen und sicheren Zugriff auf Ressourcen voraus. Bei der Entscheidung, auf welchen Technologien Informationsobjekte abgelegt werden, sollten technische Attribute eine möglichst geringe Rolle spielen. Dies wird heute über Virtualisierung erreicht. Bei den Speichervirtualisierungslösungen ist zwischen Virtualisierung im Online-, Nearline- und NASBereich zu unterscheiden. Der Online-Bereich unterscheidet zwischen server-, netzwerk- und speichersystembasierten Lösungen. Bei den netzwerkbasierten Lösungen haben sich im Wesentlichen die In-Band-Lösungen etabliert. Diese Lösungen basieren auf Appliances, die zwischen Server- und Speichersystem platziert werden. In-BandLösungen fassen auch heterogene Speichersysteme zu einem Pool zusammen und präsentieren Teilbereiche als virtuelle Logical Unit Number (LUN). Vergleichbare Lösungen gibt es auch für den Nearline-Bereich. Auch hier wird die Trennung der logischen Sicht von der physikalischen Sicht realisiert. Im Nearline-Bereich ist die Einführung einer logischen Sicht noch wichtiger, da

136

4 Schlüsselfaktor ILM-Modell

Abb. 4.19. Der Speicherrouter in der Lösungsarchitektur

traditionelle Anwendungen mit den Nearline-Gerätecharakteristika konfrontiert sind. Ein hohes Maß an Virtualisierung wird z. B. auch durch NAS-Systeme erreicht. NAS-Systeme exportieren dateiorientierte Informationsstrukturen. Die Virtualisierung erlaubt es sogar, dass unterschiedliche Plattformen auf dieselbe Datei zugreifen (beispielsweise Windows über das CIFS-Protokoll, UNIX über NFS). NAS-Systeme verbergen physikalische Speichereigenschaften in Richtung Anwendungsserver komplett. In vielen Unternehmen sind die Ergebnisse der Bemühungen zur Verbesserung der Effizienz entmutigend. Nicht einmal jede zehnte Firma verzeichnet eine Erfolgsquote von 90 Prozent.112 39 Prozent der befragten 400 Prozessverantwortlichen in Mittelstands- und Großunternehmen gaben an, dass sie ihre Projektziele zur Prozessgestaltung nur zur Hälfte bis drei Viertel erreichen. Bei 28 Prozent der Firmen fallen die Ergebnisse noch schlechter aus. Als wesentliche Schwierigkeiten bei den Projekten nennen etwa zwei Drittel lange Realisierungszeiten und begrenzte personelle Ressourcen. In der Praxis erweisen sich zudem Akzeptanzschwierigkeiten seitens der Mitarbeiter als typische Hürden auf dem Weg zum Projekterfolg. Sie sind bei 62 Prozent die zentralen Gründe für die beschriebenen unbefriedigenden Ergebnisse. Eine mögliche Schlussfolgerung ist der Verzicht auf eine sehr stark IT-lastige Prozessgestaltung, wie sie in ILM erforderlich ist. Eine zweite und sehr viel näher zur betrieb 112

Egip Software AG, www.egip.com.

4.4 Herausforderung für die strategische IT-Planung

137

lichen Realität liegende Interpretation der Ergebnisse ist in der Schwäche heutiger Lösungen zu suchen. Die Hauptschwäche heutiger Lösungen liegt in der mangelnden Integrierbarkeit verschiedener Software. Ein Ziel muss es daher sein, den traditionellen und IT-lastigen Gedanken von Business Process Management (BPM) im Rahmen eines ILM-Konzeptes zu überwinden. Die Prozessunterstützung muss sich dabei insbesondere auf die Endto-End-Prozesse beziehen. Dabei ist natürlich im operativen Bereich die Frage der optimalen Unterstützung durch die verschiedenen Speichermedien von Bedeutung.

4.4 Herausforderung für die strategische IT-Planung 4.4.1 Beispiel: Banken und Versicherungen Die abnehmende Kundenloyalität hat erhebliche wirtschaftliche Konsequenzen. Der hohe Akquisitionsaufwand für Neukunden, das begrenzte Umsatzwachstum pro Kunde durch fehlende Cross-Selling-Effekte sowie die fehlende Kosteneinsparung beim Berater, der für die Betreuung von Neukunden deutlich mehr Zeit benötigt im Vergleich zur Betreuung von Stammkunden, belasten das Ergebnis. Die Banken und Versicherungen versuchen dieses Ziel über sehr unterschiedliche Strategien zu erreichen. Eine Strategie zur Kostenreduzierung ist dabei die weitere Automatisierung der Geschäftsprozesse. Bereits heute funktionieren ca. 40 Prozent aller Bankkontakte auf Basis von Bankautomaten. Weniger als 20 Prozent der Bankkunden betreten überhaupt noch eine Filiale. Eine zentrale Strategie im Wettbewerb ist die Kostenführerschaft, die durch den Einsatz der IT in allen Prozessen erreicht wird. Die Citibank sieht sich in Deutschland als Kostenführer. Dank weitgehender Industrialisierung der Abläufe konnte die deutsche Tochter des weltgrößten Finanzkonzerns Citigroup vergangenes Jahr erstmals die Kosten-Ertrags-Relation unter 40 Prozent drücken. Damit gibt sie weniger als 40 Cent für jeden erlösten Euro aus. Schon früh hat die Citibank begonnen, nach dem Vorbild der Automobilindustrie ihre Bankprozesse zu industrialisieren. Die zentrale Fabrik der deutschen Tochter der Citigroup ist heute – nachdem die Standorte Nordhorn und Aachen aufgelöst worden sind – in Duisburg. Hier arbeiten rund 2 000 Mitarbeiter. Sie nehmen den Filialen mehr und mehr Verwaltungstätigkeiten ab, sie vergeben beispielsweise alle Kundentermine. Dabei überbuchen sie ähnlich wie Fluggesellschaften die Termine, um eine höhere Ausnutzung der Arbeitszeiten der Berater zu erreichen. Auch die Postbank hat diesen Trend erkannt und ihre Präsenz in der Fläche deutlich reduziert. Drei von fünf Banken investieren zurzeit in den Aufbau personalisierter Angebote im Internet, so eine Studie des F.A.Z.-Institutes.113 Die Versicherungen folgen diesem Trend.  113

F.A.Z.-Institut; www.faz-institut.de.

138

4 Schlüsselfaktor ILM-Modell

Allgemeine Dienste, zum Beispiel die Erstberatung oder Produktinformationen, sollen künftig im Netz ausgebaut werden. Bereits heute ist die Selbstbedienung im Internet der günstigste Kundenkontakt. Bestellt ein Kunde in einem Call-Center, fallen für das Unternehmen 10 Euro Kosten an. Bestellt der Kunde im Internet, fallen nur 2 Euro an, so groß sind die finanziellen Vorteile des elektronischen Kundenkontaktes. Der Vorteil des Internets gegenüber dem Kundenkontakt in der Filiale ist noch einmal deutlich größer. Es gibt aber auch leidvolle Beispiele für die wechselvolle Geschichte des unbegrenzten Glaubens an das Internet, die sich erst seit kurzem in eine Erfolgsstory umschreiben lassen. Zu Zeiten des Aktien- und Internet-Hypes noch hoch gelobt, dann verhöhnt, erlebt es aktuell eine Renaissance, das Direct-Brokerage. Während noch vor einiger Zeit zahlreiche Experten einschließlich des DeutscheBank-Vorstands Hermann-Josef Lamberti die Meinung vertraten, ”Das DirectBrokerage ist tot.“, widerlegen die aktuellen Ergebnisse dies deutlich. Die drei großen deutschen Online-Broker – Comdirect, DAB Bank und Cortal Consors – arbeiten wieder profitabel. Die Gründe für die Wiederauferstehung sind sehr einfach. Es wurden die Geschäftsmodelle drastisch verschlankt. Brauchten Broker früher mehr als 10 Trades pro Kunde und Jahr, um profitabel arbeiten zu können, reicht heute bereits die Hälfte. Die Comdirect unterbietet dies sogar noch und kann nach eigenen Angaben bereits mit 4 bis 5 Trades pro Kunde und Jahr leben. Die Ausgliederung kompletter Geschäftsprozesse – Business Process Outsourcing (BPO) genannt – steht ganz oben auf der Agenda der Banken und Versicherungen. Plötzlich sollen Funktionen ausgelagert werden, die bisher als unverzichtbare Kernkompetenzen galten. Die Deutsche Bank hat hierzu bereits 1999 die European Transaction Bank (ETB) gegründet, deren Namen als Programm zu verstehen war. Bislang hat die ETB allerdings nur zwei kleine Bankkunden auf ihre Abwicklungsplattform zu locken vermocht. Lambertis Bemühungen, auch andere Großbanken auf die ETB zu ziehen, lösten eine Vielzahl von Verhandlungen aus, bei denen zeitweilig buchstäblich jeder mit jedem verhandelte. Mehrfach wurden Gemeinschaftsprojekte sondiert, nach einiger Zeit aber wieder verworfen. Als Stolperstein erwies sich oft Uneinigkeit darüber, welche der bereits jeweils existierenden IT-Abwicklungsplattformen genutzt werden solle – und wer somit die kostspielige und technisch riskante Migration von seinem alten auf das neue IT-System auf sich nehmen sollte. Die Dresdner und Deutsche Bank glauben durch eine gemeinsame Abwicklung zusammen knapp 100 Mio. Euro pro Jahr zu sparen. Zwar stellte sich bisher bei den Gesprächen auf Fachebene meist heraus, dass die Bankvorstände die technischen Schwierigkeiten und Kosten solch einer Migration oft unterschätzt und damit das Einsparpotenzial oft überschätzt hatten. Beide müssten aber zunächst auch investieren. ”Die Frage ist, wie viel eigenes Geld man jetzt in die Hand nehmen muss“, sagte ein mit der Situation vertrauter Banker gegenüber der F.A.Z.114 Zudem  114

F.A.Z.-Institut, a.a.O.

4.4 Herausforderung für die strategische IT-Planung

139

Abb. 4.20. Optimierungspotenzial durch ILM bei Banken und Versicherungen aus Sicht von EMC2 115

würden die Wettbewerber Deutsche Bank und Dresdner Bank bei einer gemeinsamen Abwicklung von Zahlungsverkehr und Wertpapieren bisherige Kernkompetenzen aufgeben. Das mit vielen Hoffnungen gestartete Projekt der Großbanken, über den Aufbau einer gemeinsamen Transaktionsbank erhebliche Kostenvorteile zu erzielen und damit den Finanzplatz Frankfurt insgesamt voranzubringen, steht damit evtl. zwar vor dem Ende, ähnliche Projekte der Sparkassen sowie der Genossenschaftsbanken könnten aber nun an Fahrt gewinnen. Für das Auslagern von Betriebsprozessen sprechen vor allem Kostenerwägungen. Aus den bisherigen Fixkostenblöcken werden variable Kosten. Statt Kapazität vorzuhalten, die den Spitzenbedarf decken kann, ruft das betreffende Unternehmen nur die Leistung ab, die es gerade benötigt. Realisiert der OutsourcingDienstleister Größenvorteile (”Economies of Scale“), die er an seine Kunden weitergeben muss, so ergeben sich weitere Kostenvorteile.

4.4.2 Beispiel: Forschende Pharmaunternehmen Der Wertschöpfungsprozess der forschenden Pharmaunternehmen besteht aus einem Geflecht von einzelnen Prozessen, die teilweise in eigner Regie, teilweise in Kooperation mit Dritten, teilweise zwingend von Dritten bearbeiten werden  115

2

EMC , a.a.O.

140

4 Schlüsselfaktor ILM-Modell

Abb. 4.21. Optimierungspotenzial forschender Pharmaunternehmen116

und die es zu koordinieren gilt. In der Praxis gibt es hier meist einige „Bottlenecks“, die den Fluss der Informationen zwischen den beteiligten Partnern verzögern. In der Durchführung der Forschung, der Koordination der klinischen Tests und der Vorbereitung der Produktion sind eine Vielzahl von Daten und Prozessen zu speichern, die per Telefon, Fax, E-Mail und „shared“-Daten ausgetauscht wurden. Die dabei zu überwindenden Herausforderungen sind fehlender „shared Access“ bzw. Zugang, fehlende Angleichung der verschiedenen SecurityStandards usw. Notwendig ist eine durchgängige Methode der Speicherung des „Sharing“ von Informationen über Abteilungs- und Unternehmensgrenzen hinweg, wie es zurzeit nur ILM leisten kann.

4.4.3 Beispiel: Produktionsunternehmen Während die Fertigungstiefe der Autohersteller 1995 noch bei 40 Prozent lag, sind sie heute nur zu rund 25 Prozent an der Produktion ihrer eigenen Autos beteiligt. Unternehmen wie Continental liefern neben Felge und Reifen die komplette Achse samt Stoßdämpfer. Brose aus Coburg war einst für seine elektronischen Fensterheber bekannt. Heute baut das Unternehmen Türsysteme inklusive Scheibe, Zentralverriegelung und Schloss. Siemens VDO stellt auf der  116

2

EMC , a.a.O.

4.4 Herausforderung für die strategische IT-Planung

141

IAA ein Bedien- und Eingabesystem vor, das für Navigation und Radio die Handschrift des Fahrers erkennt. Die Entwicklung ist so weit fortgeschritten, dass Zulieferer wie Karmann in Osnabrück oder die österreichische Magna Steyr komplette Autos in Kleinserie herstellen. In Zukunft sind nicht mehr die Autohersteller diejenigen, deren Know-how die Qualität ihrer Fahrzeuge bestimmt, sondern die Zulieferer. Die Abhängigkeit nimmt mit jedem Modell weiter zu. Hier ist ILM überlebenswichtig. Wer sich in sein Opel-Astra-Cabriolet, seinen Mercedes-G-Klasse-Geländewagen, den Porsche Boxer oder sein Peugeot 406 Coupé setzt, kann sicher sein, dass sein Auto nie eine Fabrik des Autokonzerns von innen gesehen hat, dessen Namen es trägt. Seit Jahren schon vergeben alle namhaften Autokonzerne die Produktion von Modellen, von denen pro Jahr nicht mehr als 20 000 bis 30 000 Exemplare verkauft werden, an Zulieferer. Wobei die Bezeichnung „Zulieferer“ den hoch spezialisierten Autobauern längst nicht mehr gerecht wird. Sie sind die Automobilhersteller ohne eigene Marke. Die Industrieproduktion und hier insbesondere die Automobilindustrie steht vor der größten Umwälzung seit der Erfindung des Fließbands durch Henry Ford und der Einführung schlanker Produktionsprozesse durch die Japaner, dem LEAN-Management. Da die Nachfrage nach einzelnen Automodellen immer unvorhersehbarer und das Angebot an Nischenfahrzeugen immer größer wird, müssen die Autohersteller viel flexibler werden. Die Konzerne können ihre Kosten weiter erheblich senken und ihre Produktivität erhöhen, wenn sie noch stärker als bisher auf die externen Dienstleister zurückgreifen. Der Trend ist, dass die Konzerne sich auf die Entwicklung neuer Modelle konzentrieren und nur noch die großvolumigen Serien selbst produzieren. Also etwa VW den Golf oder Peugeot den Kleinwagen 206. Die übrigen Baureihen wie Cabrios, Minivans oder Geländewagen sowie Nachfragespitzen werden von Auftragsfertigern montiert. Ein Beispiel für ein erfolgreiches Unternehmen mit einer Kleinserienproduktion, das seine eigenen Nischenmodelle mit Kooperationspartnern produziert, ist Porsche. Aber erst eine IT-Infrastruktur im Sinne eines ILM-Konzeptes schafft die Voraussetzungen für die sich erst im Umrissen abzeichnenden neuen, effizienten, globalen Produktionsstrukturen. Ein weiteres Beispiel für die beschriebene Entwicklung und den ungebrochenen Trend zur virtuellen Produktion sind die großen Sportartikelhersteller Adidas, Nike und Puma. Sie alle haben bereits seit vielen Jahren keine eigene Produktion mehr. Ihre Kernkompetenzen sind Marketing, Entwicklung, Qualitätssicherung und Logistik. Die eigentliche Produktion erfolgt durch Produzenten in Lohnfertigung rund um den Globus, die zudem jeweils nur für eine einzige Serie den Zuschlag bekommen. Die so genannten virtuellen Hersteller vermarkten die Produkte dann sehr erfolgreich unter eigenem Label. Voraussetzung für den Erfolg der beschriebenen Produktion ist insbesondere die Durchgängigkeit bis zur vollständigen Integration der Informationsflüsse. Dass die fehlende Integration einer verteilten Produktion zu einem finanziellen Fiasko führen kann, zeigt aktuell das Unternehmen Airbus-Industrie mit einer

142

4 Schlüsselfaktor ILM-Modell

Abb. 4.22. Die Veränderungen in der Industrie117

Produktionsverzögerung von fast 2 Jahren und einem Verlust von fast 5 Mrd. Euro, nur weil die Planungssysteme in Hamburg und Toulouse nicht im Sinne eines durchgängigen ILM-Konzeptes zusammenarbeiten (mehr in Kap. 10). Selbst komplexe Produkte wie Autos werden bereits unweigerlich zur Massenware. Den Produzenten auch komplexer Produkte im internationalen Wettbewerb bleibt nur die Flucht in die neue Kernkompetenz Wissen und Infomationsmanagement. Produkte und Dienstleistungen sind immer stärker wissensgetrieben. Jedes Auto beweist dies. Die Mechanik wird mehr und mehr von elektronischen Bauteilen abgelöst bzw. ergänzt. Der Anteil der Information pro Produkt nimmt immer mehr zu und ist in der Wertschöpfung relevanter denn je. Gute Autos kann heute fast jeder führende Automobilhersteller bauen. Dies beweisen zurzeit die Chinesen, die faktisch aus dem Stand mit Unterstützung der etablierten Produzenten eine eigene wettbewerbsfähige Automobilindustrie aufbauen. Die Unterschiede zwischen den Marken werden immer häufiger im nichttechnischen Bereich liegen. Sie betreffen künftig die Idee der Marke, die Dienstleistungen, die Beziehung zum Kunden. In dem Maße, wie sich Autos zu einem austauschbaren Massenprodukt entwickelten, müssen sich z. B. die Automobilproduzenten zu Mobilitäts- und zu Finanzierungsexperten weiterentwickeln, bei denen die eigenen Produkte nur noch die Basis für künftige Geschäftsmodelle bilden.  117

2

EMC , a.a.O.

4.4 Herausforderung für die strategische IT-Planung

143

Abb. 4.23. Die Bedeutung der IT bei Veränderungen in der Produktion

Wie verbessern nun Unternehmen im beschriebenen Wettbewerbsumfeld ihre Marktposition? Eine große Studie zeigt: Die Führung muss auf radikale Innovationen setzen – und nicht auf Kostensenkungen.118 Die IT und die Informationsverarbeitung, insbesondere im Rahmen einer ILM-Strategie, liefern hierzu einen entscheidenden Beitrag.



118

Harvard Business Manager, 03/2006.

5 Strategische Einführungskonzepte für ILM

5.1 ILM als Projekt 5.1.1 ILM ist kein Projekt, das eine schlampige Vorbereitung verträgt! Ein Beispiel für ein solch missratenes Projekt war die LKW-Maut. Toll Collect, ein Zusammenschluss aus Deutscher Telekom, DaimlerChrysler und dem französischen Autobahnbetreiber Cofiroute, wollte ein wirklich „innovatives System“ entwickeln. „Einfach, benutzerfreundlich, flexibel und weltweit einsetzbar“. Einfach? Flexibel? Innovativ? Die Realität sah sehr lange gründlich anders aus. Bei Toll Collect regierte monatelang das Chaos. Erst die Übernahme der Verantwortung durch das Management der Telekom und die Auswechselung des Managements bei Toll Collect brachte das Projekt auf die Erfolgsspur. Dass z. B. Deutschlands größter Chiphersteller Infineon mit seiner hausinternen Informationstechnik nicht auf dem neuesten Stand war, scheint kaum vorstellbar. Und doch war der erste große Führungsfehler des geschassten Vorstandschefs Ulrich Schumacher genau darauf zurückzuführen. Infineons Computersysteme waren unzureichend vernetzt. So hatte das Topmanagement nur eingeschränkt und verzögert Zugriff auf wichtige Informationen wie Lagerbestände, Auftragseingänge oder Verkäufe – und so den sich abzeichnenden Nachfrageeinbruch in der Chipindustrie schlicht übersehen. Das Resultat war, in der letzten Chipkrise hat Infineon Verluste von rund zwei Mrd. Euro aufsummiert. Der Blindflug im Management-Cockpit war und ist keine Spezialität des im Streit geschiedenen Infineon-Piloten.119 Sie ist in deutschen Konzernen – mehr oder minder stark ausgeprägt – eher die Regel denn die Ausnahme. Ob Banken oder Fluggesellschaften, Versicherungen oder Handelshäuser, in vielen Rechenzentren tun, zumindest in Teilbereichen, noch Rechner und Software ihren Dienst, die längst veraltet sind. Viele deutsche Unternehmen nutzen noch immer veraltete IT. Das rächt sich, die Kosten steigen, die Wettbewerbsfähigkeit sinkt und unkalkulierbare Risiken entstehen. Betrieb und Pflege der IT werden insbesondere durch die Altsysteme bei Soft- und Hardware immer teurer. Vor allem, wenn noch Software im Einsatz ist, deren Programmiersprachen inzwischen nur noch Ruheständler beherrschen. Veraltete IT wird zum Wachstumshemmnis für 

119

Wirtschaftswoche 15/04, www.wiwo.de.

146

5 Strategische Einführungskonzepte für ILM

viele Unternehmen. Komplexe Systeme erschweren die Verwaltung und Wartung der IT. Derzeit verwenden Unternehmen rund 70 Prozent ihrer IT-Budgets für die Pflege ihrer bestehenden IT-Infrastruktur. Das belegt eine Studie der Metagroup. Bis zum Jahr 2006 soll dieser Anteil auf 80 Prozent steigen.120 Dadurch stehen immer weniger Mittel für Investitionen in neue Technologien zur Verfügung. Andererseits werden meist nur 20 bis 35 Prozent der verfügbaren Rechen- und Speicherkapazitäten tatsächlich genutzt. Kurze Time-to-Market-Zyklen, Fusionen, Übernahmen sowie Kostenreduktion erfordern in den Unternehmen eine neue Denkweise. Dabei spielt die Informationstechnologie (IT) eine zentrale Rolle. Nur mit IT-Strategien, die flexible und dennoch stabile Geschäftsprozesse erlauben, halten Unternehmen mit den Marktentwicklungen Schritt. Denn leistungsfähige IT ist in den vergangenen Jahren zum wichtigen, oftmals gar entscheidenden Wettbewerbsfaktor geworden. Von Online-Banking über Logistikmanagement bis zur Just-in-time-Fertigung – kaum eine Innovation in der Unternehmensführung funktioniert ohne die Unterstützung durch moderne Hard- und Software. Neue Geschäftsprozesse wie die Verknüpfung der eigenen Warenwirtschaftssysteme mit denen von Zulieferer oder Kunden lassen sich mit Altsystemen – wenn überhaupt – nur mit großem Zeitaufwand einführen. Insbesondere die Einführung von ILM muss natürlich den beschriebenen Umstand berücksichtigen und darauf aufsetzen. Unverzichtbar ist dabei die Erarbeitung eines Einführungsmodells.

5.2 SNIA-Stufenmodell Nachdem im Rahmen der strategischen IT-Infrastrukturplanung die Voraussetzungen für die Einführung von ILM geschaffen wurden, muss nun im Rahmen der strategischen Einführungskonzepte noch die Schrittfolge festgelegt werden. Die Storage Network Industry Association (SNIA) hat hierzu eine Roadmap definiert mit dem Ziel, die Einführung von ILM entlang eines logischen Weges zu lenken, der die Best-Practices-Erfahrungen der aktuellen Lösungen berücksichtigt. Die Roadmap hat das Ziel, eine sichere Basis herzustellen, und endet bei einem vollautomatisierten, multistandortbasierten Enterprise ILM. Hierzu wird die SNIA-Roadmap in 5 Phasen geteilt, von denen jede einen charakteristischen Schritt beschreibt.

5.2.1 Phase 1 Aus Sicht von SNIA, die die Autoren aufgrund ihrer einschlägigen Erfahrungen teilen, braucht ILM eine fundierte Basis. Die SNIA-Empfehlung ist, zuerst die Speicherung und die Datendienstleistungen in einer SAN- oder NAS-Umgebung zu konsolidieren. Durch Reduktion der Vielfalt und die Standardisierung der  120

Meta Group, a.a.O.

5.2 SNIA-Stufenmodell

147

Konfigurationen wird eine funktionale Architektur vorbereitet, auf der ILMDienstleistungen aufbauen können.

5.2.2 Phase 2 Das Ziel von Phase 2 ist es, die Speicherung und die Datendienstleistungen zu standardisieren, so dass es zu konsistenten, wiederholbaren und rationellen Prozessen kommt. Es fängt mit einer Datenklassifizierung an. Dabei wird gemäß den Anforderungen von existierenden und geplanten Datenzugriffen analysiert und dokumentiert. Die Daten sollen u. a. den Wert jener Auskunft für das jeweilige Geschäft dokumentieren. Dieser Wert kann in einem weiteren Schritt dazu genutzt werden, zu bestimmen, welchen wirtschaftlichen Schaden die Nichtverfügbarkeit von Daten oder gar der Anwendung für den Geschäftsprozess und das Unternehmen hat. Es kann fremde Werte wie Risiko und den mit dem Verlust der Daten verbundenen Imageschaden einschließen. Der Wert der Daten führt dann zur Definition von Dienstleistungszielen (SLOs), deren Nivellierung, Verfügbarkeit, Betriebsrückgewinnung, Katastrophenrückgewinnung, Sicherheit und mehr. Indem die Anwendungen und Daten mit standardisierten Konfigurationen verbunden und die gewünschten SLOs erreicht wurden, kann eine Bewertung zwischen der Dienstleistung und dem für die Erbringung der Dienstleistung notwendigen Aufwand ermittelt werden, der Kosten-Leistungs-Angemessenheitskoeffizient.

5.2.3 Phase 3 Diese Phase führt den Begriff von „Stacks“ ein. Ein Lösungsstack beschreibt eine Gruppe von gleichartigen Daten und Dienstleistungen, die Instrumente geworden sind, die in Verbindung mit ILM den Support von Anwendung und den Informationswert der Daten sichern. Ein Lösungsstack ist eine vollständige (oder beinahe vollständige) ILM-Umgebung für eine dezidierte Anwendung. So basiert im Stack ein SLO für einen Anwendungsfall auf der Beschreibung der ersten aktiven Speicherung, der Wiederherstellung und dem Katastrophenfallschutz sowie dem Archivierungsaufbewahrungsort. Dies ist der erste Schritt für ein automatisiertes ILM.

5.2.4 Phase 4 Für die ILM-Automation wird die Einführung einer neuen Klasse von Managementwerkzeugen benötigt. ILM wird hier zuerst in Form einer homogenen Insel betrieben. Industrieerfahrung zeigt, dass es weit leichter ist, zuerst ein Instrument einer einzelnen Applikation zuzuordnen. Dabei wird eine schrittweise Durchführung korrespondierend mit der Lösung der Fragen im Hinblick auf die benötigten Daten und Auskünfte plus dem Aufbau des Netzes, der Services und der Speicherinfrastruktur erreicht werden können. Insbesondere der erforderliche Abgleich mit dem benötigten Serviceniveau ist aus wirtschaftlicher Sicht ein zwingendes

148

5 Strategische Einführungskonzepte für ILM

Abb. 5.1. SNIA-Roadmap zur Einführung von ILM121

Vorgehen, Der Nachweis der Nützlichkeit der Datenverarbeitung, Netzdienstleistungen und Informations-Services-Dienstleistungen in Verbindung mit einem nivellierten Management von Industriegruppen wie DMTF, OASE, IETF, GGF, EGA, ITSMF, ITIL und mehr schaffen für die Unternehmen echten Mehrwert.

5.2.5 Phase 5 In Phase 5 wird erstmalig die Interoperabilität erreicht. Interoperabilität bedeutet, dass Produkte ihre Möglichkeiten definieren und die Instrumente bereitstellen für die angebotenen Service-Dienstleistungen. Dabei kann ein Service auch durch andere ersetzt werden, so dass Service-Dienstleistungen auf sehr unterschiedlichen Wegen erbracht werden können. Interoperabilität ist die friedliche Koexistenz zwischen den Services und kein Wettbewerb um Ressourcen, so dass z. B. die Datenverwaltung die Erzeugung von informationsbasierten Produktservices nicht stört. Interbetriebsfähigkeit ist das Ergebnis einer Beschreibung und Ausgestaltung, die Schnittstellen so zu definieren, dass es zu keinem konkurrierenden Zugriff auf Informationen kommt. Für ILM bedeutet dies, die Fähigkeit zu entwickeln, das bestehende Komplexitätsproblem bei der Datenzentralisierung bei gleichzeitiger substanzieller TCO-Reduzierung zu lösen, indem auf  121

SNW, a.a.O.

5.3 BITKOM-Prozessmodell

149

Geschäftsanforderungen und auf einem durch SLA definierten Niveau geplant und gearbeitet wird. ILM ist damit das perfekte Instrument für die Automatisierung der zentralen Informationsverwaltung und -speicherung.

5.3 BITKOM-Prozessmodell Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) stellt in einem Leitfaden ein ILM-Konzept vor, das aus den folgenden Prozessen besteht: x Erstplatzierung der Daten: Die Erstplatzierung legt fest, in welcher Speicherklasse ein Informationsobjekt gespeichert werden soll. Die Definition der Klassen ist unternehmensspezifisch. x Replikation: Die Replikation von Daten erfolgt entweder über Mirroring oder über Point-in-Time (PIT-) Mechanismen). Dabei werden sämtliche Daten möglichst aktuell repliziert, respektive nachgeführt. x Datensicherung: Die Datensicherung basiert auf einem Versionsschema. Informationsobjekte werden in regelmäßigen Abständen kopiert, ohne dass das Original zerstört wird. So kann auch auf ältere Versionen desselben Speicherobjektes zugegriffen werden. x Archivierung: Die Archivierung ist eine gezielte Speicherung von Informationsobjekten in eine andere Speicherklasse. Dabei wird definiert, wie lange ein Informationsobjekt nicht gelöscht werden darf (Vorhaltefrist – Retention). x Verdrängung (Hierarchical Storage Management): Die Verdrängung verschiebt ein Informationsobjekt von einer Speicherklasse in eine andere ohne Veränderung der Zugriffssyntax. x Verlagerung: Die Verlagerung eines Informationsobjektes ist ein irreversibler Vorgang, der vor allem beim Einsatz neuer Hardware zum Zuge kommt. x Löschen und Zerstören: Beim Löschen wird ein Informationsobjekt lediglich logisch freigegeben, während das Zerstören eines Objektes eine Garantie beinhaltet, dass ein Informationsobjekt nie mehr gelesen oder rekonstruiert werden kann. Der erste Schritt in Richtung ILM beginnt mit der Erfassung und Klassifizierung aller im Unternehmen vorhandenen Daten. Dabei geht es um den Wert der Informationen für das Unternehmen. x Wie kritisch ist jede einzelne Datei und jeder Datensatz für die Geschäftsprozesse? Gibt es rechtliche Archivierungsvorgaben? x Welche Anwendungen benötigen sie, und in welcher Form greifen sie darauf zu? Erst wenn klar ist, welche Informationen vorhanden sind und welche Anforderungen sie an ihren Speicherort stellen, lassen sich die nötigen Servicelevels für die Speicherumgebung formulieren.

150

5 Strategische Einführungskonzepte für ILM

Im Detail bedeutet dies die Beantwortung der folgenden Fragen: x Verbindung von Datenklassifizierung mit weiteren, wichtigen Datenmanagementfunktionen – darunter Backup und Recovery, Datenreplikation sowie Reporting-Werkzeuge – um Zeit, Kosten und wertvolle IT-Ressourcen zu sparen. x Parameter zur besseren Strukturierung von Daten für optimalen Schutz, verbesserte Verwaltung sowie Vorhaltung basierend auf vordefinierten Richtlinien. x Verschiebung der Unternehmensdaten auf die jeweils geeignete Speicherebene entsprechend vordefinierter Richtlinien. x Umfassende Datenprüfung im Vorfeld und Datenklassifizierung zur Reduzierung des Zeitaufwands für Datenbewegungen sowie der Serverauslastung.122 Beide ILM-Einführungskonzepte haben noch keinen „State of the Art“-Charakter. Sie zeigen, dass sowohl eine strategische Sicht (SNIA) in Form eines Phasenkonzeptes als auch ein operativer Maßnahmenkatalog (BITKOM) notwendig sind, der im Idealfall ein hohes Maß an kausaler Konjunktion aufweist.

5.4 Strategische ILM-Prozessmodelle Zwar ist ILM kein fertiges Produkt, sondern eine Kombination von Prozessen, trotzdem muss das Ziel der Prozesse zumindest in Umrissen definiert werden. Auch hier hat sich noch kein klarer Standard etabliert.

5.4.1 ILM als Prozessmodell Eine Möglichkeit zur besseren Abstimmung von IT und Unternehmensgeschäft liefert das „Strategic-Business-IT Alignment Model“ (SAM). Dieses Modell bestimmt das Zusammenspiel zwischen Geschäftsstrategie, -strukturen und -prozessen sowie der IT-Strategie und der Ausgestaltung im Detail innerhalb von zwei Dimensionen: einerseits innerhalb der „funktionalen Integration“ und andererseits im Rahmen des „strategischen Fits“. Das Modell verdeutlicht, dass alle Größen einander eng bedingen und Änderungen in den einzelnen Bereichen auch die anderen Abteilungen beeinflussen. Die Information-Technology-Infrastructure-Library-Methode (ITIL) setzt auf dem SAM-Modell auf. In einem Kreislauf aus Konzeption, Realisierung und permanentem Check-up wird die Ausrichtung der IT am Unternehmensgeschäft überprüft und notfalls korrigiert. ITIL liefert eine umfassende Sammlung von Standards in den Bereichen Aufgaben, Prozesse sowie Kennzahlen der IT insgesamt und zeigt deren Anwendung anhand von praktischen Beispielen. Gerade die Ausrichtung der IT am Unternehmenszweck und der Geschäftsentwicklung ist ein zentraler Aspekt dieser Methode. Das Besondere ist die freie Verfügbarkeit und der freie Zugang  122

BITCOM, www.bitkom.de.

5.4 Strategische ILM-Prozessmodelle

151

Abb. 5.2. ILM als Prozessmodell Enterprise Content Management (ECM)

zu diesem Werkzeug. Analog zum Kreisprozess der Ausrichtung erfolgt die Behandlung der Information. ILM besteht im Kern aus dem Dokumenten Management System (DMS) und aus dem so genannten Enterprise Content Management (ECM). ECM umfasst gemäß der Definition des Branchenverbandes AIIM die Technologien zu Erfassung, Verwaltung, Speicherung, Bewahrung und Bereitstellung von Dokumenten und Content zur Unterstützung von organisatorischen Prozessen.123 ECM schließt dabei sowohl Produkte als auch Lösungen und Strategien ein und umfasst Technologien wie Business Process Management (BPM), Collaboration, Dokumentenmanagement, Input- und Output-Management, Record Management, Storage und elektronische Archivierung sowie Web Content Management (WCM) und Workflow. Die Zahl der ECM-Anbieter ist groß, denn viele gute Lösungen für die beschriebenen Teilbereiche wollen sich dadurch mehr Bedeutung verleihen, dass sie sich als ECM-Produkt definieren und nicht etwa als Speicherspezialist.

5.4.2 ILM als Modell mit dem Fokus Speicherung der Information Ein Gegenpool zur Sicht, dass es sich bei ILM um eine reine ContentManagement-Lösung handelt, ist die Vorstellung, ILM als ein Tool der Speicher 123

AIIM, The Enterprise Content Management Association, www.aiim.org

152

5 Strategische Einführungskonzepte für ILM

fraktion zur Optimierung der kostengünstigen Bereitstellung von Speicher aufzufassen. Moderne Speichersysteme sind längst mehr als simple Datenträger. Mit jeder neuen Generation wandert Intelligenz aus dem Betriebssystem in die Peripherie, um dort das Informationsmanagement zu optimieren. Die Folge ist, dass die Datenbanken flexibler, schneller und günstiger werden. Letztlich hat hier IT nur die eine Aufgabe, die richtigen Informationen rechtzeitig bereitzustellen. Spezielle Speichersoftware trägt dazu bei, Informationen verfügbar zu machen und toten Speicherplatz zu vermeiden. In der Praxis hat sich trotzdem in den letzten Jahren ein Wildwuchs, bestehend aus verschiedenen Herstellerlösungen, mangelndem herstellerübergreifendem Management und fehlendem Know-how entwickelt. ILM beschreibt hier den radikalen Schnitt. Bestes Beispiel ist der Speicherwildwuchs der Client-ServerÄra, der vielerorts nicht mehr verwaltbar ist. Die Ursachen sind vielfältig und heißen unter anderem immer größerer Speicherbedarf, immer mehr Applikationen, stark heterogen geprägte Strukturen und zersplitterte Datenhaltung. Buchstäblich jeder Geschäftsvorgang hat heute ein digitales Abbild, sei es in Form eines Datenbankeintrags, einer Rechnung oder der Korrespondenz über E-Mail. Hinzu kommt, dass die Benutzer Daten im Zweifelsfall lieber speichern als löschen. Selbst wenn der Preisverfall bei Speicher für einen Kapazitätsausbau sprechen mag, es bleiben zwei Aspekte zu bedenken: x Erstens erhöht mehr Speicher auch den Managementaufwand. x Zweitens sind die bestehenden Speicherressourcen oft nur mangelhaft ausgelastet. Die Speichernutzungsbilanz liegt heute im Durchschnitt bei gerade einmal 40 Prozent. Abgesehen davon, dass mehr Ressourcen vorhanden sind, als sich nutzen lassen, besteht generell ein Managementproblem, das beträchtliche administrative Kosten verursacht. Client-Server-Strukturen haben dazu geführt, dass immer mehr Dateninseln entstanden sind. Nur hier greift der Ansatz, ILM als die Lösung der Speicherfraktion mit dem erstem Schritt zur Konsolidierung anzusehen. Je nachdem, welche Architektur eine Speicherplattform aufweist, lassen sich mehr oder weniger große Konsolidierungseffekte erzielen. Den größten Effekt bietet eine so genannte Unified-Storage-Architektur, die buchstäblich jeder beliebigen Applikation unter verschiedenen Betriebssystemen einen „artgerechten“ Datenzugriff erlaubt und die dafür nötigen Protokolle auf einer universellen Plattform unterstützt. Damit genügt es auch, eine einzige Kopie der Daten vorzuhalten, die allen Benutzern und Applikationen zur Verfügung steht. Konsolidierung an sich bietet bereits eine Reihe von Vorteilen, die sich in erster Linie aus der Zentralisierung des Managements ergeben. Das Qualitätsniveau von Backup und Recovery steigt, was sich insbesondere bei einem standortintensiven Filialbetrieb bezahlt macht, der in der Regel kein IT-Personal vor Ort hat und dennoch die Verfügbarkeit sicherstellen muss. Die Skalierbarkeit ver-

5.4 Strategische ILM-Prozessmodelle

153

Abb. 5.3. ILM als Tool zur Erreichung einer Unified-Storage-Architektur124

bessert sich ebenso wie die Antwortzeiten und Ressourcenauslastung. In Kombination mit einer Speichervirtualisierung erschließen sich weitere Optionen, die nicht nur die Speichernutzung optimieren, sondern auch flexible, serviceorientierte Prozesse ermöglichen. Bei der Virtualisierung unterbricht eine Abstraktionsschicht die direkte Verbindung zwischen Festplatten und Daten, so dass flexible Datencontainer entstehen, die nicht mehr direkt auf den Festplatten abgebildet (d. h. gemappt) werden. Die Gefahren einer einseitig IT-lastigen Herangehensweise an ILM dürfen nicht verschwiegen werden. Es gibt eine Reihe von Faktoren, bei denen sich die erfolgreichen Unternehmen von den weniger Erfolgreichen unterscheiden. Der wichtigste jedoch ist, dass die oberste Managementebene bei Schlüsselentscheidungen im IT-Bereich eine echte Führungsrolle einnimmt. Wenn Führungskräfte diese Entscheidungen ganz den IT-Managern überlassen, ist die Katastrophe vorprogrammiert. Dies belegen die vielen Beispiele von verpfuschten Einführungen breit angelegter Systeme zum Customer Relationship Management (CRM) und Enterprise Resource Planning (ERP). Es wäre falsch zu glauben, das Fiasko mit diesen CRM- und ERP-Systemen sei das Resultat rein technologischer Patzer beim Einrichten und Starten der komplizierten Anwendungen. Tatsächlich war das Problem in der Regel ein anderes, die Führungskräfte erkannten nicht, dass 

124

EDS, SNW, a.a.O.

154

5 Strategische Einführungskonzepte für ILM

die neuen Systeme nicht nur eine technische bzw. IT-technische, sondern insbesondere eine unternehmerische Herausforderung darstellten, vergleichbar ILM. Entsprechend übernahmen sie keine Verantwortung für die notwendigen Veränderungen der Organisation und der internen Prozesse.

5.4.3 ILM als Modell mit dem Fokus Adaptive Enterprise Damit Unternehmen möglichst großen wirtschaftlichen Nutzen aus den ITInvestitionen ziehen und einen schnellen Return on IT (RoIT) erzielen, sollten sie aber auf innovative Technologien setzen. Diese sorgen dafür, dass Ressourcen flexibel dort bereitstehen, wo sie tatsächlich benötigt werden – und zwar in dem Umfang, der für die aktuelle Aufgabe notwendig ist. So verfügt das Unternehmen über eine IT-Infrastruktur, die sich den Geschäftsprozessen anpasst, eine so genannte adaptive Infrastruktur. Bei konsequenter Umsetzung wandelt sich das Unternehmen zum Adaptive Enterprise, das in Echtzeit auf Marktbedingungen reagiert. Erreicht wird dies durch die Technologie Utility Computing. Es handelt sich hierbei um ein verbrauchsorientiertes Modell. Die Anwender erhalten die Rechen- und Speicherleistung, die sie tatsächlich benötigen, aus einem großen zentralen Pool. Auf diese Weise werden die vorhandenen Systeme optimal ausgelastet. Grundvoraussetzung für dieses Modell ist ein intelligentes, automatisiertes Management der IT. Es gewährleistet, dass für Geschäftsprozesse immer die richtigen IT-Services zur Verfügung stehen. Eine ideale IT-Infrastruktur, die sämtliche Kapazitäten in einem großen virtuellen Pool vorhält, der zentral verwaltet wird und je nach Bedarf verteilt, folgt diesen Prinzipien: x x x x x

Einfach, Modular, Integriert heterogene IT-Landschaften, Nutzt standardisierte Prozesse und Berücksichtigt die spezifischen ILM-Anforderungen.

Bei der Auswahl neuer Systeme wird berücksichtigt, dass sie leicht zu beschaffen, zu betreiben und zu warten sind. Modulare Bausteine erlauben Änderungen einzelner Geschäftsprozesse, ohne dass die gesamte IT beeinflusst wird, und erhöhen dadurch die Reaktionsgeschwindigkeit. Die Integration schafft eine einheitliche Systemwelt, die künstliche Barrieren zwischen den Systemen abbaut und so Kapazitäten unternehmensweit nutzbar macht. Standards lassen sich für Arbeitsabläufe, Technologien und Anwendungen festlegen. Das erleichtert unter anderem auch das Management der IT. Die enge Vernetzung von Geschäftsprozessen mit ILM und der IT muss auf einer Architektur basieren, die aus einer Lösung für die Ressourcen-Virtualisierung und einer Plattform für das Systemmanagement besteht. Eine wichtige Komponente dabei ist die Systemmanagementsoftware. Ausgereifte Systemmanagementsoftware wie beispielsweise Microsoft MOM oder HP OpenView ist modular aufgebaut. Sie kombiniert vorhandene Elemente zum erforderlichen

5.5 Aktuelle ILM-Trends

155

Service, der sich nach dem Bedarf der entsprechenden Abteilung richtet. Außerdem überwacht sie die Performance und plant den weiteren Bedarf. Diese adaptive Managementplattform vereint die verfügbaren Ressourcen im Rechenzentrum. So lassen sie sich effizienter nutzen und verwalten. Mit der Hilfe einer ausgefeilten IT-Strategie, die auf einer flexiblen Managementplattform aufsetzt, können Unternehmen dann ihre Investitionen gemäß den Geschäftszielen ausrichten und gleichzeitig den Nutzen ihrer IT für das Geschäft messen.

5.5 Aktuelle ILM-Trends Ein aktueller Trend sind plattformübergreifende, regelbasierte Speichermanagementsysteme. Nach Einschätzungen der Meta Group wird sich das plattformübergreifende, regelbasierte Speichermanagement mittelfristig durchsetzen.125 Die applikationsbezogene Automatisierung des End-to-End-Managements von unternehmensweiten Speichernetzen wird zu erheblich verbesserten Speichernutzungsraten führen. Damit erhöhen sich die Anwendungsverfügbarkeit und -leistung. Dazu gehören die Applikationen Monitoring, Detection, Reporting, Auto-Provisioning und adaptive Resource Management. Darüber hinaus werden so genannte Enterprise Content Management (ECM-) Systeme allein aufgrund der ständig steigenden Datenflut und gesetzlicher Vorschriften zur Archivierung von Informationen erheblich an Bedeutung gewinnen. Diese Archivierungsvorschriften werden auch von der Content-basierten Speicherlösung erfüllt. Noch sind die meisten der heute bereits angebotenen Softwarelösungen, die als ILM-Solutions vertrieben werden, dedizierte Speziallösungen, mit denen Anwender ihre Daten sichern, bewegen, konsolidieren oder automatisiert wiederherstellen können. Dazu gehören Backup- und Recovery-Produkte sowie Tools für das hierarchische Speichermanagement und die Plattenvirtualisierung. Der wahre Wert von ILM für den Anwender ergibt sich längerfristig durch die Kombination intelligenter, plattformübergreifender Speichersoftware mit effizientem Data Lifecycle Process Management. Dies ist auf folgenden Voraussetzungen aufgebaut: x Kategorisierung der Datentypen (E-Mail, Transaktionen). x Verknüpfung von Datentypen zu Business-Regeln (Security, Recovery Point Objective/Recovery Time Objective). x Festlegen der Service Levels. Diese SLAs müssen pro definiertem Datentyp die geschäftlichen Anforderungen betreffen. x Die Unternehmen müssen Storage Services aufbauen, basierend auf der Fragestellung, welche Speicherarchitektur möglichst flexibel die SLAs und deren Anforderungen unterstützt.



125

Meta Group, a.a.O.

156

5 Strategische Einführungskonzepte für ILM

5.6 Überprüfung der Voraussetzungen für ILM-Projekte Die folgenden Punkte sollen dazu dienen, zu überprüfen, ob die eigene Unternehmens-IT oder der IT-Partner fit ist für die anstehenden ILM-Projekte. Werden einige davon negativ beurteilt, dann sollten die Alarmglocken läuten. x Benutzerzufriedenheit Computeranwender sind zwar nie wirklich mit ihrem System zufrieden. Eine wachsende Zahl von Beschwerden oder lange Reaktionszeiten bei Supportanfragen weisen allerdings auf Probleme hin. x Eigenentwicklungen Wie viele Anwendungen entwickelt die IT-Abteilung selbst? Wie stark greift sie auf Standardsoftware zurück? Bei zu vielen Eigenentwicklungen besteht die Gefahr, dass die IT-Abteilung sich nicht auf ihre Kernfunktion als interner Dienstleister für die Nutzer der Geschäftsprozesse konzentriert. x Inkompatible Software Wie heterogen oder homogen ist die IT-Landschaft? Gibt es mehrere komplexe Unternehmenssoftwaresysteme parallel für Finanzplanung, Personalwesen oder Produktionssteuerung? Wenn ja, können die Programme miteinander Daten austauschen? Falls nicht, droht ein teures Informationschaos, das die Wettbewerbsfähigkeit beeinträchtigt. x Kosteneffizienz Die IT-Ausgaben in Prozent des Unternehmensumsatzes sind zwar stark branchenabhängig, liegen aber in der Regel zwischen zwei und vier Prozent. Weichen die Werte deutlich ab, dann produziert die IT die Services zu teuer. x Personalfluktuation Herrscht in der IT-Abteilung ein häufiges Kommen und Gehen? Eine hohe Fluktuationsrate ist ein wichtiger Indikator für interne Probleme. x Projekte Hakt es bei der Einführung neuer Hard- oder Software? Wenn IT-Projekte häufig vereinbarte Termine überschreiten, mehr Kosten als geplant verursachen oder Projekte ohne Erfolg abgebrochen werden müssen, fehlt das nötige Projektmanagement einschließlich Projekt- und Effizienzkontrolle. x Systemabstürze Laufen die Arbeitsplatzrechner sowie das Computernetzwerk nicht stabil und stürzen häufig Softwareprogramme ab? Häufige Systemabstürze sind Indizien, dass die IT-Abteilung die Systemwartung vernachlässigt und zudem ein unzureichendes Systemmanagement betrieben wird. x Verärgerte Partner Gibt es häufig Ärger mit externen IT-Dienstleistern oder läuft die Zusammenarbeit reibungslos? Zunehmende Beschwerden oder wachsender Zahlungsverzug deuten auf Probleme hin.

5.6 Überprüfung der Voraussetzungen für ILM-Projekte

157

x Viele Viren- und Hackerangriffe Häufen sich erfolgreiche Viren- oder Hackerangriffe, ist das ein Hinweis auf ein fehlendes umfassendes IT-Sicherheitskonzept. Dies kann im schlimmsten Fall zum Ausfall der kompletten Computersysteme führen – damit auch ein Hinweis auf ein schlechtes Management der IT-Infrastruktur sein. x Wenige Innovationen Gibt es in der IT Erweiterungs- und Neuinvestitionen oder werden nur noch die vorhandenen Systeme gewartet? Die Ausgaben für Neuprojekte sollten nicht unter die Schwelle von 20 Prozent aller Ist-Kosten sinken.

6 ILM aus Sicht des Projektmanagements

6.1 Projektmanagement Wie in Kap. 4, Schlüsselfaktor ILM-Modell, begründet, muss bei sechs Entscheidungen das Management selbst die Führungsverantwortung übernehmen, wenn es ein IT-Desaster vermeiden und – noch wichtiger – echten Nutzen aus seinen IT-Investitionen ziehen will. Keine dieser Entscheidungen sollte alleine von IT-Leuten getroffen werden, denn das ist nicht ihr Job. Die zentrale Frage ist, besteht ein „Fit“ zwischen der Unternehmensstrategie, der hieraus abgeleiteten IT-Servicestrategie und ILM und ist die eigene Unternehmens-IT „fit“ für ein ILM-Projekt. In den erfolgreichen Unternehmen legt das Management zuerst die strategische Rolle der Informationstechnik für das Unternehmen fest, dann bestimmt es ein unternehmensweites Budget – eines, mit dem die festgelegten Ziele erreicht werden können. Die Ziele unterscheiden sich je nach Unternehmen erheblich. Manche sind relativ bescheiden, wenn es zum Beispiel nur darum geht, Ungenauigkeiten und Ineffizienzen in den Verwaltungsabläufen zu beseitigen. Die Ziele können aber auch entscheidend für die gesamte Unternehmensstrategie sein, zum Beispiel die Aufrechterhaltung einer nahtlosen weltweiten Lieferkette oder eines reibungslosen Kundendienstes, aber auch die Unterstützung einer hoch entwickelten Forschungs- und Entwicklungsabteilung. Solch unterschiedliche Ziele erfordern natürlich unterschiedliche Budgets. Und wenn die Informationstechnik eine zentrale strategische Rolle spielen soll, dann sind damit die notwendigen Ausgaben verbunden. Erst auf Basis der strategischen Entscheidung lassen sich die Ziele im Rahmen von ILM ableiten: die Projektziele. Ein Projekt ist eine Institution, der eine sachlich und zeitlich begrenzte Aufgabe zugewiesen wird, die durch das Zusammenwirken unterschiedlicher Funktionsbereiche gelöst werden soll. Projekte zeichnen sich dadurch aus, dass sie x x x x

fest vorgegebene Ziele besitzen, außerhalb der üblichen Geschäftstätigkeit liegen, einmalig oder zumindest neuartig sind und das Projektteam sich aus einer hierarchieübergreifenden, heterogenen Mitarbeiterstruktur verschiedener Funktionsbereiche zusammensetzt.“126

 126

Huch, B., Behme, W., Ohlendorf, T.: Rechnungswesenorientiertes Controlling, 2. Aufl., Heidelberg , 1995, S. 348 f.

160

6 ILM aus Sicht des Projektmanagements

Hieraus wird deutlich, dass es sich bei Projekten um Aufgabenstellungen von besonderer Größe und Komplexität handelt. Die Terminierung von Anfang (Projektfreigabe) und Ende (Projektabnahme) ergibt sich vielfach aus der Auslösung eines Projektes. Infolge des subjektiven Ausgangspunktes ihrer Identifizierung werden Projekte unterschieden in interne, vom Unternehmen selbst ausgelöste Projekte, und externe, denen als Auftrag eines Kunden, eine Anfrageund Angebotsphase vorhergeht.127 Der zeitliche Rahmen eines Projektes kann sich von der Projektidentifizierung über die Projektfreigabe bis zur Projektabnahme über mehrere Jahre erstrecken. „Die Projektplanung beinhaltet die Erarbeitung von Zielen und Maßnahmen im Bezug auf Leistungen, Termine, Ressourcen und Finanzen.“128 Sie setzt mit der Freigabe des Projektes ein. Leistungen, Termine, Ressourcen und Finanzen gelten als Projektparameter/Projektziele/Bezugsgrößen eines jeden Projektes und weisen einen gegenläufigen Charakter auf (eine Terminverkürzung verursacht zum Beispiel zusätzliche Kosten). Abgeleitet aus der Zielsetzung, welche mit dem Projekt verfolgt wird, werden entsprechende Zielgrößen für die einzelnen Projektparameter geplant. „Zum Zwecke der Komplexitätsreduktion werden Projekte in ihre Teilaufgaben (Prozesse) zerlegt. Die kleinsten Einheiten einer solchen Zerlegung werden Aktivitäten genannt. Eine Aktivität ist ein zeitverbrauchender Vorgang (Tätigkeit), der durch einen Anfangs- und einen Endzeitpunkt gekennzeichnet ist und im Allgemeinen einen Kostenanfall auslöst.“129 Die Einteilung der Zeitabschnitte kann in Perioden oder auch durch Festmachung an so genannten Meilensteinen vorgenommen werden. Auf Grundlage einer so genannten Projektstrukturplanung erfolgen die Ablauf-, Zeit- und Terminplanung, die Ressourcen- und Kapazitätsplanung und die Kosten- und Budgetplanung. Die Erstellung eines Projektfinanzplanes ergibt sich häufig schon sehr frühzeitig, da meist eine Vorfinanzierung der Projekte über einen längeren Zeitraum erforderlich ist. Nachdem die Projektziele definiert sind, geht es darum, den Weg zu deren Erreichung zu beschreiben. Hierbei ist ein hohes Maß an Disziplin notwendig. Ein Beispiel für die disziplinierte Weise, mit der ein Unternehmen in den vergangenen Jahren das Thema IT-Investitionen angegangen hat, ist Delta Airlines. „1997 erlebte das Unternehmen eine Technologiekrise. Einige Jahre zuvor hatte die Airline die EDV-Verwaltung ausgelagert. Doch die einzelnen Geschäftsbereiche waren unzufrieden mit dem Service und bauten eigene IT-Ressourcen und entsprechende technologische Fähigkeiten auf. Die Existenz unterschiedlicher Systeme in den einzelnen Abteilungen erschwerte den Mitarbeitern jedoch einen pünktlichen und zuverlässigen Kundendienst.“ 

127

128 129

Schmitz, H., Windhausen, M.P.: Projektplanung und Projektcontrolling, 3. Aufl., Düsseldorf 1986, S. 2. Aeberhard, K., a.a.O., S. 385. Dellmann, K.: Eine Systematisierung der Grundlagen des Controlling, in: Spremann, K.; Zur, E. (Hrsg.): a.a.O., S. 130.

6.1 Projektmanagement

161

Abb. 6.1. Das Projektziel ILM

Die Frage „An welchem Gate kommt mein Flugzeug an“ zum Beispiel generierte bis zu 17 unterschiedliche Antworten, je nachdem, welches System der Mitarbeiter benutzte. Hinzu kam, dass viele Systeme auf alten Technologien basierten, die möglicherweise mit dem Jahr-2000-Problem nicht zurechtkommen würden. Mit derselben Weitsicht, die UPS bei der Entwicklung seiner Paket-Datenbank gezeigt hatte, nahmen die Führungskräfte von Delta das Jahr-2000-Problem zum Anlass, eine leistungsfähige Technologieplattform mit dem Spitznamen „Delta Nervous System“ (DNS) aufzubauen, die für die Flugabfertigung und die Kundenbetreuung Informationen in Echtzeit bereitstellte. Das Drei-Jahres-Projekt, das eine Milliarde Dollar kostete, versorgte jeden Mitarbeiter mit ständig aktualisierten Daten zu jedem Flug und jedem Passagier. Bei der Ausarbeitung der Vision für das System trafen die Manager eine weitere wichtige Entscheidung: Sie verzichteten darauf, zugleich in ein neues Umsatzplanungssystem zu investieren.“130 Entscheidungsträger erkennen zunehmend die erheblichen Einsparmöglichkeiten und strategischen Vorteile, die unternehmensweit zentralisierte IT-Leistungen und eine standardisierte IT-Infrastruktur mit sich bringen. Dieser Ansatz macht die vorhandene technologische Expertise unternehmensweit nutzbar, erlaubt weit reichende und kostengünstige Verträge mit Softwareanbietern und 

130

Manager-Magazin, www.manager-magazin.de.

162

6 ILM aus Sicht des Projektmanagements

erleichtert globale Geschäftsprozesse. Gleichzeitig können Standardisierungen aber die Beweglichkeit einzelner Geschäftsbereiche beschneiden und die Fähigkeit des Unternehmens beschränken, flexibel auf unterschiedliche Kundensegmente einzugehen. Und sie können den Widerstand der Geschäftsbereichsleiter herausfordern. Wenn IT-Managern die Entscheidung überlassen wird, was zentralisiert und vereinheitlicht werden soll und was nicht, wählen sie in der Regel eine von zwei Vorgehensweisen. Je nach Unternehmenskultur vereinheitlichen sie entweder alles, um Kosten zu sparen. Oder sie erkennen die Wichtigkeit autonomer Geschäftsbereiche und machen für jeden aufbegehrenden Bereichsleiter Ausnahmen. Die erste Möglichkeit beschränkt die Freiheit der Fachbereiche, die zweite ist teuer und erschwert Synergieeffekte. In manchen Fällen arbeiten Systeme mit unterschiedlichen Standards sogar gegeneinander – es entsteht eine IT-Infrastruktur im Unternehmen, die insgesamt weniger wert ist als die Summe ihrer Teile. Folglich sollten Topmanager bei diesem entscheidenden Prozess der Interessenabwägung die Führungsrolle übernehmen. Die operative Umsetzung der beschriebenen ILM-Strategie wurde bereits im Projektbeispiel beschrieben. Aufgrund der eigenen Erfahrungen können die beiden Autoren die Bedeutung einer Umsetzung in Stufen, die sich im Sinne eines Spiralmodells wiederholen, nur betonen. Die Projektmanager erreichen damit einen stetigen Know-how-Aufbau in Verbindung mit einer kontinuierlichen Qualitätsverbesserung. Die immer wieder zu durchlaufenden Einzelstufen ermöglichen es zudem, die bedingt durch die lange Projektlaufzeit notwendige Ein- und Ausphasung der Mitarbeiter zu bewerkstelligen. Der Weg zum Ziel ILM, gleich ob als x Networked Tiered, x ILM für einzelne Applikationen oder x ILM für das gesamte Unternehmen, besteht aus den 4 Schritten, die in Abhängigkeit vom Gesamtziel mehr oder wenig häufig durchschritten werden. Die zentrale Frage, die es noch auf strategischer und auf operativer Ebene zu beantworten gilt, ist die Frage, wie werden die notwendigen Entscheidungen getroffen. Den Verantwortlichen in den Unternehmen steht seit knapp hundert Jahren jede Menge Handwerkszeug zur Verfügung. Zeitlich spannt sich der Bogen von der „wissenschaftlichen Betriebsführung“ des Frederick Taylor über die amerikanischen Management-by-Methoden der Nachkriegszeit, militärstrategische Ableitungen aus Deutschland (Harzburger Modell), fernöstliche Weisheiten (Kaizen, Kanbai) bis zu komplexen Führungsmodellen (Sieben S), Qualitätsansätzen (Total Quality Management (TQM), Turn around Konzepten, Business Process Reengineering (BPR)) und Shareholder Value, um nur die bekanntesten zu nennen. Ein Unternehmen kann – je nach Kultur, Strategie und Struktur – zwischen unterschiedlichen Ansätzen wählen. Aber in jeder guten IT-Managementstruktur ist festgelegt, wer für die zentralen Entscheidungen verantwortlich ist und

6.1 Projektmanagement

163

Abb. 6.2. Der Weg zur Zielerreichung

auch zur Rechenschaft gezogen werden kann. Zum Beispiel werden IT-Investitionen häufig im Rahmen der unternehmensweiten Budgetplanung bestimmt, die vom Topmanagement abgesegnet wird. Entscheidungen über die IT-Architekturen und die mit ihnen verbundenen Standards werden oft von Ausschüssen getroffen, denen technische und kaufmännische Manager angehören. In jedem Fall aber gewährleistet ein effektives IT-Management, dass EDV-Entscheidungen die Rolle der IT im Unternehmen widerspiegeln. Das Unternehmen sollte aber sicherstellen, dass alle IT-Entscheidungen mit Blick auf die neue Strategie getroffen werden, den Kunden über alle Geschäftseinheiten hinweg mit einem einheitlichen Erscheinungsbild gegenüberzutreten. Dieser Ausschuss gibt die Marschrichtung der Informationstechnik im Rahmen der Unternehmensstrategie vor und erarbeitet ein übergreifendes IT-Budget, das die Bedürfnisse des Gesamtunternehmens und der einzelnen Geschäftsbereiche ausbalanciert. In der Struktur des IT-Managements spielt der CIO eine aktive Rolle bei der Entwicklung der IT-Strategie und bei der Förderung der effektiven Nutzung von Informationstechnik. Gleichzeitig zeigt das Komitee das IT-Engagement der Führungsriege des Unternehmens inklusive des Chief Operating Officers. Nachdem die zentralen Fragen: x Ziel, x Vorgehensweise und x Entscheidungsstruktur entschieden sind, ist nur noch zu klären, ob das Ziel ILM als Projekt organisiert oder in den Fachabteilungen durchgeführt wird. Gleichwohl muss diese Frage

164

6 ILM aus Sicht des Projektmanagements

Abb. 6.3. Die Schritte zum Ziel ILM

mit der Form des Managements in Einklang gebracht werden. Beim Management kann man zwischen zwei Hauptströmungen klar unterscheiden: x die rationalen Zahlen- und Controlling-orientierten Methoden (Shareholder Value, Balanced Scorecard) sowie x die sozialen, menschenorientierten Konzepte (lernende Organisation, Motivationsansätze). Welche Schule gerade den Ton angibt und in der Gunst der Manager vorne liegt, hängt von der wirtschaftlichen Lage ab. In guten Zeiten entwickelt man großzügig Mitarbeiter und Organisationen weiter. In schlechten Zeiten regieren die Rechner und Kassenwarte. Dann müssen „quick shots“ her, damit die Bilanzen glänzen. Trotz der Anforderung, auch kurzfristig das Unternehmen in der Erfolgsspur zu halten, darf im Rahmen von ILM eine langfristige Sicherung der Wettbewerbsposition nicht vernachlässigt werden. Die Aufgabe der kurzfristigen Erfolgssicherung übernimmt das Projektcontrolling

6.2 Projektcontrolling Für den Begriff Controlling gibt es keine einheitliche Übersetzung. Aufgaben und Inhalte des Projektcontrollings als Teil des gesamten Projektmanagements werden sogar in der Fachliteratur recht unterschiedlich erwähnt.

6.2 Projektcontrolling

165

Der traditionelle Kontrollbegriff im Sinne des einfachen Soll-Ist-Vergleichs darf hier nicht als direkte Übersetzung für den Begriff Controlling verstanden werden, sondern bezeichnet lediglich Kontrolle als eine Teilfunktion des Controllings. Die gesamte Tragweite des Begriffes und die Aufgaben eines Controllers werden meist wie folgt definiert: Die Controlleraufgabe ist gemäß dem instrumentalen Controlling-Begriff „vorrangig die Schaffung und Bereitstellung von Instrumenten und Techniken zur Informationsbeschaffung, Planung und Kontrolle sowie Steuerung“ 131, und „Controlling ist – funktional gesehen – ein Subsystem der Führung, das Planung und Kontrolle sowie Informationsversorgung systembildend und systemkoppelnd koordiniert … Controlling stellt damit eine Unterstützung der Führung dar.“132 Bezogen auf ein identifiziertes ILM-Projekt stellen somit – in Anlehnung an diese Definitionen – Projektplanung, Projektsteuerung und Projektkontrolle sowie Projektbericht und Projektdokumentation die wichtigsten Teilaspekte des Projektcontrollings dar. Dieser funktionale Aspekt des Controllings spezifiziert die Aufgabe eines Projektcontrollings relativ weit reichend und nimmt Abstand von der reinen Serviceaufgabe, welche lediglich eine allgemeine Mitwirkung des Controllers an der Projektrealisierung vorsieht.133 Um jedoch ein effektives Projektcontrolling betreiben zu können, ist es zunächst wichtig, Projekte organisatorisch in das Unternehmensgefüge einzugliedern. Da Projekte, wie bereits erwähnt, einen erheblichen zeitmäßigen Umfang erfordern und sie gleichzeitig einen hohen Wert für das Unternehmung darstellen, ist es ratsam für die Zeitdauer dieser Vorhaben eine eigenständige Organisationsform zu etablieren. „Anzustreben ist ein Controlling, das in der Lage ist, das Projekt unabhängig von betrieblichen Grenzen (Abteilungen, Bereiche) und unabhängig von Hierarchien über die gesamte Projektdauer zu begleiten.“134 Im Gegensatz zu anderen Controlling-Feldern, wie zum Beispiel dem Funktionsbereichscontrolling, wo Bereiche wie Beschaffung, Produktion, Marketing etc. ohne zeitliche Terminierung/Begrenzung fortwährend gesteuert werden, wird zur Bewältigung eines Projektes eine solche zeitlich befristete, eigenständige organisatorische Einheit mit einem Projektverantwortlichen als Leiter gebildet. Diese organisatorische Einheit gilt als autonomes Subsystem mit eigener Erfolgsrechnung und kann auch einen Profit-Center darstellen. Da das Einliniensystem als Leitungssystem wohl das häufigste ist, soll dieses autonome Subsystem hier als Stabliniensystem ausgestaltet und das Projektcontrolling als Stabstelle deklariert sein. Die hierarchische Eingliederung kann sowohl auf einer Ebene mit dem Projektleiter als auch zwischen diesem und den Projektteams  131 132 133 134

Huch, B., Behme, W., Ohlendorf, T., a.a.O., S. 44. Horváth, P.: Controlling, 5. Aufl, München, 1994, S. 144. Welge, M. K.: Unternehmungsführung, Bd. 3: Controlling, Stuttgart, 1988, S. 318. Spalinger, B.,: Kosten und Nutzen neuer Projekte, Controlling, Wiesbaden, 1992, S. 446.

166

6 ILM aus Sicht des Projektmanagements

Abb. 6.4. ILM als Gesamtmodell auf Basis von Einzelschritten

erfolgen. Die Projektteams bestehen aus Mitarbeitern der verschiedenen Fachabteilungen, welche für die Projektdauer ganz oder teilweise freigestellt werden und fachlich dem Projektleiter unterstehen. Wichtig bei dieser Institutionalisierung ist die Kompetenzenausstattung der Projektleitung durch die Unternehmensleitung. Die „Projekt-Controlling-Stellen haben keine Entscheidungskompetenz; die Projektverantwortung liegt bei der Projektleitung …“135 Der Projektleiter selbst ist einem Mitglied der Linienorganisation unterstellt. Durch die starre Funktionstrennung in Entscheidungsvorbereitung durch den Stab (Controller) und Entscheidung durch die Linie (Projektleiter) können sich jedoch auch die üblichen Problemfelder einer Stablinienorganisation (mangelnde Akzeptanz, Informationsbereitschaft) ergeben. Die Vorteile dieser organisatorischen Gestaltung des Projektcontrollings als ein autonomes Subsystem können aus den Merkmalen des zentralen/dezentralen Controllings abgeleitet werden: Der Controller ist nah am Objekt (Projekt), kennt somit entsprechende Detailinformationen und kann Zielabweichungen besser interpretieren. Anpassungsund Steuerungsmaßnahmen können unmittelbar durch den Verantwortlichen  135

Aeberhard, K., Spremann, K.: Controlling von Projekten bei Banken, S. 388.

6.3 Projektsteuerung und Controlling

167

durchgeführt, Maßnahmen direkt ergriffen werden, was eine rasche Zielerfüllung begünstigt. Als Nachteile können sowohl die Gefahr der Suboptimierung als auch Zielkonkurrenzen zwischen Bereichs- und Unterzielen in allen Phasen des Projektcontrollings genannt werden. Eine reine Projektorganisation auf Gesamtunternehmensebene ist in Unternehmen mit einer entsprechenden objektorientierten Organisationsstruktur jedoch auch praktizierbar und würde lediglich die primäre Organisationsstruktur ohne weitere Subsysteme beinhalten. Die zentrale Aufgabe des Projektcontrollings im Rahmen eines ILM-Projektes ist: x Die Schaffung und Bereitstellung von Instrumenten und Techniken zur Informationsbeschaffung, Planung und Kontrolle sowie Steuerung auf Basis der entwickelten Schritte. x Der Soll-Ist-Vergleich im Rahmen einer flexiblen Plankostenrechnung, die insbesondere den Realisierungsgrad der Umsetzung der Einzelschritte des Projektes ausreichend berücksichtigt.

6.3 Projektsteuerung und Controlling „Die Projektsteuerung umfasst die Erarbeitung von Korrekturmaßnahmen bei Planabweichungen sowie die Koordination von Aufgaben und Tätigkeiten innerhalb eines Projekts ... “ 136 „Mit der Projektkontrolle wird die Überwachung der in der Projektplanung festgelegten Parameter von laufenden ... und eingeführten Projekten sichergestellt.“137 Den in der Projektplanung festgelegten wirtschaftlichen Einsatz von Leistungen, Terminen, Ressourcen und Finanzen gilt es, auch weiterhin während der gesamten Projektdauer zu gewährleisten. Entscheidend ist eine integrierte Betrachtung der Projektparameter. Der Projektcontroller wertet hierzu vorhandene Daten aus (vergangenheitsbezogene Kontrolle), analysiert frühzeitig Störungen, wirtschaftliche Schwachstellen und Risiken, überwacht Ausgaben und Einnahmen und steuert zukunftsbezogen (Gegensteuerungsmaßnahmen bei Abweichungen), um die entsprechende Planerfüllung zu erzielen. „Somit kann Projektcontrolling auch als Instrument zur Früherkennung von Chancen und Bedrohungen verstanden werden.“138 Durchführung von Trend- und Risikoanalysen zum frühzeitigen Erkennen von quantitativen und qualitativen Fehlentwicklungen sowie auch der Vergleich der Projektpläne (Leistungs-, Termin-, Ressourcen- und Finanzplan) mit dem aktuellen Projektstand konkretisieren dieses Instrument. 

136 137 138

Aeberhard, K., a.a.O., S. 385. Aeberhard, K., a.a.O., S. 385. Huch, B., Behme, W., Ohlendorf, T.: a.a.O., S. 353.

168

6 ILM aus Sicht des Projektmanagements

Abb. 6.5. ILM aus Projektsteuerungs- und Controllingsicht

6.4 Projektrisikomanagement Insbesondere für das Projektrisikomanagement gilt: „Dinge wahrzunehmen ist der Keim der Intelligenz.“139 Wertorientierung und Wachstum – welche Risiken können solche Ziele beeinflussen? Diese Frage vorausschauend zu beantworten, ist die Herausforderung für das Risikomanagement. Dass das Risikomanagement bei ILM-Projekten untrennbar mit strategischer Planung verbunden ist, liegt auf der Hand. Dabei geht es nicht nur um die Frage, ob etwas Negatives eintritt, sondern auch darum, ob etwas Positives nicht realisiert werden kann. Entsprechend gestalten sich die Instrumente der strategischen Planung. Die strategische Analyse liefert die erforderlichen Informationen, zum Beispiel über verändertes Verhalten der Wettbewerber, neue rechtliche Rahmenbedingungen oder gravierende Marktbewegungen. Risiken werden auf diese Weise antizipiert. Die Instrumente zeigen frühzeitig, welche möglichen Risiken das Unternehmen daran hindern könnten, das Ziel zu erreichen. Diese Informationen werden bewertet und Gegenmaßnahmen – soweit erforderlich – in Gang gesetzt. Vor unserem Erfahrungshintergrund und dem Fehlen erfolgreicher Umsetzungen auf Basis der Arbeiten der Fachabteilungen schlagen wir natürlich das Aufsetzen eines ILM-Projektes unter einem zentralen Projektmanagement vor, wie unser  139

Laotse (ca. 400 v. Chr.), http://www.paradigma.net/paradex/bin/view/ParaDeutsch/Potentialforschung.

6.4 Projektrisikomanagement

169

Abb. 6.6. Ziel ist das Entstehen der Daten ILM-konform abzuwickeln

Beispiel zeigt. Die größten Kosteneinsparungspotenziale bei den Lifecyclekosten ergeben sich, wenn ILM bereits beim Entstehen der Daten ansetzt. Das Risikomanagement in ILM-Projekten muss neben der Bedrohung der Wettbewerbsposition auch den Grad der Effizienz der Informationsbereitstellung berücksichtigen. Nur 63 Prozent unserer Arbeitszeit sind wir produktiv. Nach einer Studie der Unternehmensberatung Proudfoot Consulting liegt das nicht am einzelnen Mitarbeiter, sondern am Management und an einer ungeeigneten Informationsbereitstellung.140 Der Hauptgrund für unproduktive Arbeitszeit sind mangelhafte Führungssysteme, die eigentlich gewährleisten müssen, dass Informationen vom Sachbearbeiter zum Unternehmenschef gelangen. Das Problem ist, dass die verschiedenen Hierarchieebenen Informationen filtern. Die Aufgabe von Managern ist es, formalisierte Systeme zu installieren, auf die alle einen Zugriff haben, so dass beispielsweise auch der Manager von Reklamationen erfährt und ein Servicemitarbeiter nachschauen kann, welche Lösung beim letzten Mal nach einem Ausfall eines Systems gefunden wurde. Ohne ein System zur gezielten Informationsbereitstellung ist nicht sichergestellt, dass die richtigen Informationen an den richtigen Stellen einsehbar sind, bzw. gefunden werden. Risikomanagement im Rahmen von ILM hat weitere Aufgaben. Durch Systeme mit dem zweideutigen Namen „BalPlan“ (Balanced Scorecard Planning System) 

140

Proudfoot Consulting, a.a.O.

170

6 ILM aus Sicht des Projektmanagements

kann man verhindern, dass das ILM-Projekt keinen Beitrag zur Verbesserung der Wettbewerbsposition leistet. Mit z. B. drei Zukunftsszenarien können die Auswirkungen unterschiedlicher Entwicklungen antizipiert und darauf aufsetzend alternative Reaktionen bewertet werden. Die Stärke der Balanced Scorecard ist, dass nicht nur harte, sondern auch weiche Faktoren gemessen werden, und dann in die Bewertung einfließen. Die vom BSI befragten Fachleute erwarten, dass das Ausspähen von Unternehmensdaten in den kommenden Jahren noch zunehmen wird.141 Auch hier muss das Risikomanagement einen Beitrag leisten. Führungskräfte, und zwar nicht nur aus den IT-Abteilungen, sind in puncto IT-Sicherheit als ergebnisorientierte Vorausdenker gefordert. Das Vorausdenken (samt entsprechendem Management) sieht so aus, dass der Finanzchef sich angewöhnt, mit virtuellen Zahlen zu rechnen und den Wert von Sicherheits-Investments und -Betriebskosten zu akzeptieren, ohne dass sich eine Katastrophe als negatives Rechenbeispiel aufdrängt. IT-Manager sind in der paradoxen Lage, dass die Qualität ihrer sicherheitsrelevanten Arbeit umso weniger offenkundig wird, je höher sie ist. Wo kein Virus durchkommt und die Systeme störungsfrei laufen, begreift der Vorstand nicht immer, wozu er denn schon wieder ein Sicherheitsprojekt abnicken soll. Und in den Fachabteilungen wird leicht vergessen, dass die bequemste und leistungsfähigste IT-Anwendung nicht immer auch die sicherste ist.



141

BSI, a.a.O.

7 Schlüsselfaktor Klassifizierungskonzepte

7.1 Fehlende Strukturierung Das Management von unstrukturierten Daten ist noch immer eines der größeren unaufgeklärten Probleme der Speichertechnologien. Noch sind vermutlich ca. 80 Prozent der gespeicherten Daten unstrukturiert und entziehen sich so einem ökonomischen ILM-Prozess. Die zentrale Herausforderung der prozesskonformen Bereitstellung besteht jedoch für strukturierte und unstrukturierte Daten. Zwar wurde das ILM-Konzept von den Speicherherstellern entwickelt, die Malaise der fehlenden Strukturierung hat zur Konsequenz, dass aktuell noch die Hauptprotagonisten die Beratungshäuser sind. „Es dauert Stunden über Stunden, um in Assessments, eine Datenklassifizierungen und so weiter herauszufinden, wo

Abb. 7.1. Herausforderung prozesskonforme Informationsbereitstellung142



142

2

EMC ; www.emc.com.

172

7 Schlüsselfaktor Klassifizierungskonzepte

Abb. 7.2. Lösungsalternativen143

es bei den ILM-Projekten letztendlich hingeht“, so Netapp.144 So bieten inzwischen viele Hersteller vorgelagerte Beratung an, ehe ILM implementiert wird. „Wir erarbeiten mit dem Kunden einen Soll-Ist-Vergleich und bewerten diese Daten kundenspezifisch nach einem bestimmten Schema“, so ein Business Development Manager für ILM-Systeme von Sun Microsystems.145 Auch StorageTek bestätigt, dass man sich „mit den Unternehmensberatern verbrüdern“ muss: „Wenn ein Storage-Anbieter wie wir, der für seine Hardware bekannt ist, sagt, wir machen Geschäftsprozessanalysen, dann ist das sicherlich etwas unglaubwürdig.“146 Alle aktuellen Lösungskonzepte für die Datenklassifizierung basieren auf: x Tiered Storage: Es bezeichnet ein mehrstufiges Speichernetzwerk. Jede Ebene bildet spezifische Serviceziele ab, so dass Daten entsprechend ihren Anforderungen gespeichert werden können. x Virtualisierung: Sie trennt die logische von der physikalischen Sicht auf die Infrastruktur. So können die Daten im Hintergrund verschoben werden, ohne den Zugriff der Anwendungen zu beeinträchtigen. Kommt eine gut durchdachte Datenklassifizierung zum Einsatz, so lassen sich die Daten strukturiert speichern und damit unterschiedliche Strategien leichter 

143 144 145 146

2

EMC , www.emc.com. Netapp; Pressemitteilung, www.netapp.com. SUN, Pressemitteilung, www.sun.com. StorageTek, Pressemitteilung, www.storagetek.com.

7.2 Speicherklassifizierungskonzepte

173

umsetzen und auch anspruchsvolle Service Level Agreements (SLA) effizienter einhalten. Konzepte wie ILM mit mehrstufiger Speicherung, der gezielten Risikoverminderung, dem Anspruch auf Einhaltung gesetzlicher Regelungen und ein optimiertes Projektmanagement stellen bei ausgefeilter Datenklassifizierung keine unerfüllbaren Wünsche dar.

7.2 Speicherklassifizierungskonzepte Auf der Basis der vorgestellten ILM-Modelle erfolgt die notwendige Klassifizierung der Daten. Die Klassifizierung ist dabei ein zentraler Eckstein für den Erfolg des ILM-Modells. Eine allgemeine Klassifizierung von Daten wird üblicherweise in Form einer Einordnung in eine drei- bis fünfstufige Gruppe bzw. Skala vollzogen. Dabei kann z. B. in Abhängigkeit der Branche unterschieden werden zwischen: x Critical Data: Daten, die für die wichtigen Geschäftsprozesse benötigt werden und deren Verlust zu einer operativen Katastrophe führen kann (die Unternehmensleistung kann nicht mehr erbracht werden), sowie Daten, die aus rechtlichen Gründen aufbewahrt werden müssen. x Business Performance Data: Daten, die für die Steuerung und die Planung eines Unternehmens relevant sind und deren Verlust zu einer unternehmerischen Katastrophe führen kann. x Essential Data: Daten, die für das Tagesgeschäft verwendet werden und damit Teil des Business-Know-hows eines Unternehmens sind. x Sensible Data: Daten, die für das Tagesgeschäft verwendet werden, die jedoch entweder schnell wiederhergestellt oder durch alternative Daten ersetzt werden können. x Non-Critical Data: Daten, die mit geringen Kosten wiederhergestellt werden können oder aber Duplikate bestehender Daten. Die Kernaufgabe besteht darin, die Geschäftsprozessanforderungen auf die verschiedenen Speicherklassen im Rahmen eines „Tiered-Storage“-Modells umzurechnen. Ziel ist, x den Speicher, dem „Business“ entsprechend (Demand), mit niedrigen Kosten und hoher Qualität (Zeit, Funktion) bereitzustellen, sowie x die Trennung der Schichten Anforderung und Lieferung durchzuführen. Der Prozess der Klassifizierung assoziiert Dateien mit Metadaten und/oder Inhalten wie zum Beispiel Kategoriethema, Nutzername, Entstehungsdatum, Änderungsdatum, Inhalt und andere Kriterien. Somit kann ein Mitarbeiter nach verschiedenen Parametern suchen, um die Informationen zurückzuholen oder sie entsprechend ihrem Wert zu verwalten. Eine Klassifizierung identifiziert auch Gemeinsamkeiten in Dokumenten, was ungewollten Redundanzen vorbeugt. Das Clustering gruppiert Dateien nach Wortähnlichkeiten oder miteinander verbun-

174

7 Schlüsselfaktor Klassifizierungskonzepte

Abb. 7.3. Branchenspezifische Abhängigkeiten147

denen Informationen. In einer Taxonomie sind die Informationen in logische Hierarchien strukturiert, die die Daten in spezifische Klassen einteilen. Das jeweilige Unternehmen bestimmt diese Hierarchien nach seinen eigenen Anforderungen, beispielsweise einer Einteilung nach Abteilungen oder nach Applikationen. Erst die Datenklassifizierung gliedert alle Daten im Unternehmen in Kategorien mit bestimmten Attributen. Zu erreichen ist das durch die Klassifizierung der Daten und die Aufteilung der Informationsinfrastruktur in unterschiedliche Speicherebenen (Tiered Storage). Allerdings steigt dadurch die Komplexität der IT, und der Verwaltungsaufwand wächst. Die Verantwortlichen benötigen deshalb Lösungen, die die Administration heterogener Umgebungen vereinfachen und die Mobilität von Informationen steigern. Zum Klassifizierungsvorgang gehört, dass jede Gruppe anhand gemeinsamer Eigenschaften näher definiert wird (zum Beispiel ähnliche Serviceziele). Erst die Klassifizierung schafft die Voraussetzung für ILM und stellt demzufolge den ersten Schritt dar: x Mit dem Aufbau des Prozesses zur Klassifizierung für Speicherklassen werden die Grundlagen für eine weitere Klassifizierung der Information zum ILM erarbeitet. x Bei der Einführung von ILM müssen technische Lösungen und Prozesse eingerichtet werden. 

147

Kleineaschoff, Ulrich: Unternehmenpräsentation T-Systems, 2004.

7.2 Speicherklassifizierungskonzepte

175

Abb. 7.4. Bildung von Speicherklassen als erstem Schritt

Die Frage nach der Klassifizierung kann jedoch nur unternehmensspezifisch beantwortet werden. Ausschlaggebend dabei sind die jeweilige Ausgangssituation und die branchenspezifischen Anforderungen. Zum Beispiel ergibt sich bei einer Bank eine andere Antwort als beim ausführlich beschriebenen Fallbeispiel. Die aktuell anspruchsvollsten Anforderungen kommen aus dem Trader-Bereich von Banken. Hier gibt es Transaktionsdaten, die innerhalb von Millisekunden abgerufen werden müssen. Weniger aktuelle Informationen, zum Beispiel ein abgeschlossener Konteneröffnungsantrag, werden nur noch selten für Data Mining oder für das Berichtswesen benötigt. Dennoch müssen sie revisionssicher über einen bestimmten Zeitraum vorgehalten werden. Wieder andere Daten sind innerhalb kürzester Zeit veraltet und können oder müssen sogar gelöscht werden. Erst wenn klar ist, welche Informationen vorhanden sind und welche Anforderungen sie an ihren Speicherort stellen, lassen sich die nötigen Servicelevels für die Speicherumgebung formulieren. Der erste Schritt in Richtung einer Tiered-Storage-Umgebung beginnt somit mit der Erfassung und Klassifizierung aller im Unternehmen vorhandenen Daten. Dabei geht es um den Wert der Informationen für das Unternehmen: x Wie kritisch ist jede einzelne Datei und jeder Datensatz für die Geschäftsprozesse? x Gibt es rechtliche Archivierungsvorgaben? x Welche Anwendungen benötigen sie, und in welcher Form greifen sie darauf zu?

176

7 Schlüsselfaktor Klassifizierungskonzepte

Abb. 7.5. Die Veränderungen der Systemarchitektur148

Dabei ist zu beachten, dass sich die Systemlandschaft von Applikation zu Server und Speicher verändert und sich von einer 1:1:1-Beziehung zu einer N:N:NBeziehung wandelt. Voraussetzung für die Bildung und die Überwachung der Speicherklassen ist ein durchgängiges Messverfahren. Die Messung selbst erfolgt über spezielle Agenten und die Nutzung von API auf den Server- und Speichersystemen. Dabei muss die Zuordnung der Messdaten zur Applikation die Systemarchitektur berücksichtigen. Die Verbindung von Datenklassifizierung mit weiteren wichtigen Datenmanagementfunktionen – darunter Backup und Recovery, Datenreplikation sowie Reporting-Werkzeugen – ist zwingend notwendig, um Zeit, Kosten und wertvolle IT-Ressourcen zu sparen. Die Klassifizierung stellt folgende Parameter bereit: x Parameter zur besseren Strukturierung von Daten für optimalen Schutz, verbesserte Verwaltung sowie Vorhaltung, basierend auf vordefinierten Richtlinien. x Parameter zur Verschiebung der Unternehmensdaten auf die jeweils geeignete Speicherebene entsprechend vordefinierten Richtlinien. x Parameter zur umfassenden Datenprüfung im Vorfeld und für die Datenklassifizierung, zur Reduzierung des Zeitaufwands für Datenbewegungen sowie der Serverauslastung. 

148

Kleineaschoff, Ulrich, a.a.O.

7.3 Generische Klassifizierungsansätze

177

Abb. 7.6. Messung der Speicherklassen

Die Kalkulation der Storageklassen kann auf Basis verschiedener Ansätze erfolgen: x Generationenmodell: Hier wird jedes Jahr für neueste Hardware ein neuer Preis festgelegt. Der Preis für ältere Hardware bleibt jedoch unberührt. x Greenfield Approach: Es wird nur mit neuem, günstigerem Speicher kalkuliert. (keine Altlast). x Kontinuierlicher Refresh: Durch kontinuierlichen Refresh der „ausgelaufenen“ Speichersysteme verringern sich im Laufe der Zeit die Kosten und damit der Preis pro GB-Plattenkapazität. Diese Kosteneinsparungen sind Gegenstand der in SLA vereinbarten zyklischen Preisüberprüfungen. x Mischkalkulation: Es muss mit altem und neuem Speicher kalkuliert werden.

7.3 Generische Klassifizierungsansätze Die Datenklassifizierung unterstützt alle Maßnahmen, um gespeicherte Informationen optimal nutzen zu können. Ganz gleich ob im Content-Management, beim Dokumentenmanagement, beim Hierarchical Storage Management (HSM), beim Information Lifecycle Management (ILM) oder bei der Archivierung, die in Speichernetzen (SAN) gespeicherten Informationen müssen möglichst schnell, nach bestimmten Prioritäten und Attributen gegliedert, dem Informationsmanagement bzw. den alltäglichen Geschäftsprozessen zur Verfügung stehen. Bei der

178

7 Schlüsselfaktor Klassifizierungskonzepte

Datenklassifizierung werden die Daten in Gruppen mit bestimmten Attributen aufgegliedert. Jede Gruppe ist durch gemeinsame Eigenschaften definiert. Mit der Klassifizierung wird erreicht, dass die Daten entsprechend der vom Anwender gesetzten Priorität unter einer geeigneten Speicherinfrastruktur gepflegt werden. Größtes Problem dabei ist die fehlende Durchgängigkeit des Datenmanagements insbesondere bei verteilten Speicherstrukturen. Denn auch die derzeitige Speichertechnik ist noch immer meilenweit von dem ehrgeizigen Ziel entfernt, ein durchgängiges, wertorientiertes Datenmanagement zu ermöglichen. Bei der Klassifizierung sind die spezifischen Anforderungen des Unternehmens zu berücksichtigen. Es gibt demzufolge unterschiedliche Klassifizierungsmodelle, die entweder einen statischen Charakter (d. h. eine einmalige Festlegung) oder einen dynamischen Charakter haben (d. h. eine Änderung der Klassifizierung ist möglich). In der praktischen Umsetzung wird meist eine Kombination der einzelnen generischen Ansätze genutzt.

7.3.1 Statische Klassifizierungsmodelle 7.3.1.1 Modell: Anwendungsklassifizierung Aus Sicht der Klassifizierung stehen die Anwendungen und alle Prozesse, die Daten transformieren können, im Zentrum der Betrachtung. Anwendungen können Programme wie z. B. Adobe Acrobat sein, die Informationen zu einem Bund vereinigen, die Anwendungen maßstäblich ändern und zudem häufig die betrieblichen Datenbanken und die Filesysteme des Unternehmens überspannen. Künftige Anwendungen könnten die Fähigkeit haben, die Policy und die daraus abgeleiteten Dienstleistungsstufen zu beeinflussen, sie so direkt mit der Beauskunftung zu verbinden und somit einen Lifecycle der Auskunft aufzubauen. Derartige zukünftige Anwendungen würden „ILM-aware-Anwendungen“ heißen.

7.3.1.2 Modell: Archivierungsbasierte Klassifizierung Die Abbildung von Geschäftsprozessen und -unterlagen in elektronische Dokumente erfordert eine geeignete Ablage der entstehenden Daten für die spätere Verwendung, deren Wiederfinden und Aufbereitung. Dies betrifft sowohl Datensätze als auch die elektronische Repräsentation papierener Geschäftsdokumente und Belege. Die dauerhafte und unveränderbare Speicherung von elektronischen Dokumenten und anderen Daten wird als Archivierung bezeichnet. Nicht allein, dass steuerrelevante Dateien ggf. 10 Jahre und länger in revisionssicherer Form archiviert werden müssen. Hinzu kommt, dass die Geschäftsführung für die Sicherheit der betriebswichtigen Daten und Systeme persönlich haften kann (vgl. Kap. 2). Eine geordnete, jederzeit verfügbare Aufbewahrung der elektronischen Geschäftspost ist aber auch aus Gründen der strategischen Rechtssicherheit unabdingbar, insbesondere um das Unternehmen für eine etwaige juristische Auseinandersetzung beweisrechtlich zu positionieren. Indessen greift die uneingeschränkte Archivierung der gesamten Kommunikation

7.3 Generische Klassifizierungsansätze

179

ohne geeignete betriebliche Regelungen schnell in die Rechte der Mitarbeiter ein. In diesem Spannungsfeld diametral gegenläufiger Interessen und Rechtspflichten geht der Überblick allzu leicht verloren. Hier schafft die Klassifizierung die Voraussetzung für ILM. Insbesondere zum Thema Archivierung fordert das Bundesamt für die Sicherheit der Informationstechnologie: „Für die Archivierung elektronischer Dokumente müssen geeignete Datenformate gewählt werden. Das Datenformat sollte langfristig eine originalgetreue Reproduktion der Archivdaten sowie ausgewählter Merkmale des ursprünglichen Dokumentmediums (z. B. Papierformat, Farben, Logos, Seitenzahl, Wasserzeichen, Unterschrift) ermöglichen. Die derzeit verwendeten Datenformate sind hierfür unterschiedlich geeignet, ihre Eignung hängt sehr stark vom Einsatzzweck der archivierten Daten und ihren Ursprungsmedien ab. Bei einem Wechsel des Medien- und Datenformats können jedoch in der Regel nicht alle Strukturmerkmale des Ursprungsmediums gleichzeitig abgebildet werden. Da im Vorfeld meist nicht absehbar ist, welche Merkmale des Originaldokuments bei einer späteren Reproduktion nachgewiesen werden sollen und mit welcher Nachweiskraft dies erfolgen soll, werden Dokumente typischerweise in mehreren elektronischen Datenformaten gleichzeitig archiviert. Dadurch soll eine möglichst hohe Überdeckung der Merkmale des Originaldokuments erreicht werden. Der Konvertierungsvorgang wird häufig als Rendition bezeichnet.“149

7.3.1.3 Modell: Auskunftsklassifizierung Die Auskunftsklassifizierung ist eine grundsätzliche ILM-Strategie, die sich an der Praxis der Beauskunftung orientiert. Bei diesem Modell steht die Verwaltung von Daten im Mittelpunkt der Betrachtung. Dabei wird eine Unterscheidung zwischen Filesystem, Datumsbasierter Klassifizierung und Content basierter Klassifizierung vorgenommen. In der auskunftsbasierten Klassifizierung kommt das Konzept des Handbuchs versus vollautomatisierte Klassifizierungsverfahren (einschließlich Taxonomieentwicklung) zur Anwendung. Die Beauskunftung kann dabei auf verschiedenen Niveaus erfolgen und sich auf die Konzeption der SNIA-DMF-ILM-Initiative konzentrieren. Die aktuellen Technologien ermöglichen es, auf alle Aufzeichnungen online zuzugreifen und damit zunehmend die Zeit zwischen Archiv, Sicherstellungen und der ersten Kopie einer gelagerten Aufzeichnung zu eliminieren. Zum Beispiel sind Sicherungskopien traditionell nicht für einen Zugang geplant, außer in sehr seltenen Fällen des Totalausfalls. Diese Vorstellung basiert noch auf der traditionellen Unterscheidung zwischen verschiedenen festen Speichertechnologien, die üblicherweise benutzt werden, und den neuen Online-Speicherungen. Unternehmen können sich durch den schnelleren Zugang zu ihrer netzbasierten Datenspeicherung einen 24 u 7Zugang zu ihren Daten verschaffen und damit kontinuierlich eine Beauskunftung ermöglichen. Beispiele sind hier die Expressunternehmen mit ihrem Service der Sendungsverfolgung. 

149

BSI, www.bsi.de, a.a.O.

180

7 Schlüsselfaktor Klassifizierungskonzepte

7.3.1.4 Modell: Business-Transaction basierte Klassifizierung Basis der „Business-Transaction“-basierten Klassifizierung ist die Bewertung von Informationen. Leider existiert bis heute keine standardisierte Bewertungsmethode. Wohl gibt es Ansätze, wie die Informationsproduktivität von Paul Strassmann150, die Informationswertefunktion von Dr. Cramer151 oder auch Bewertungsbetrachtungen des Militärs152, der Wissenschaft153 oder diejenige der Cyberökonomen154. Die Bewertung der Kosten bei Datenausfall kann jedoch ebenso zur indirekten Bewertung der Unternehmensdaten herangezogen werden. Thomas Redman, der Präsident der Firma Navesik Consulting Group in New York, hat 1998 in einer Zusammenfassung einer Reihe von Untersuchungen zum Thema Datenqualität festgestellt, dass durchschnittlich 15 Prozent aller Daten eines Unternehmens fehlerhaft sind.155 Redman geht davon aus, dass 812 Prozent des Einkommens eines Unternehmens durch Datenverlust verloren gehen. Die SNIA (Storage Networking Industry Association) hat deshalb im März 2004 ein Strategiepapier veröffentlicht, welches ein Bewertungsschema enthält. Die Bewertung der Daten gemäß SNIA Business Transactions baut auf dem Modell auf, dass die Transaktionen auf Firmenebene, wie der Kauf oder Verkauf von Firmen, oder Firmenbereiche, International Purchasing Office (IPO) und Zusammenschlüsse, sowie Financial Transactions, zu denen Finanztransaktionen wie Geldüberweisungen, Verwaltung von Aktien und Portfolios zählen, für die Bewertung genutzt werden. Weitere Input-Größen für das Bewertungsmodell sind: x Customer Service: Kundendaten eines Unternehmens, wie beispielsweise Kontaktinformationen, Bestellverhalten etc. x Business Intelligence: Daten, die zur Planung und Steuerung eines Unternehmens notwendig sind. x Manufacturing Operations: Alle Daten, die für die Produktion von Gütern benötigt werden. x POS / Order Entry: Daten, die den Auftragseingang betreffen, respektive Daten aus dem Verkauf (POS: Point of Sales). x Medical Records: Patientendaten sowie Daten über die Wirkung von Medikamenten. x E-Mail Records: Alle E-Mails einer Firma mit den Attachments.  150 151 152 153

154 155

Dignan, L., Strassman, Paul: Who Led the Baseline 500 and Why, Baseline Magazine Okt. 2004. Cramer, M.L..:Measuring the Value Information, infoWAR-Congress, Viena 1997. 100-6INFO, Department of the Army, Washington, DC, USA, Field-Manuell-Nr. 100-6, 1996. Fafaeli, S., Raban, D.R.: Experimental Investigation of the Subjective Value of Information in Trading, 2003. Bauwens, M.: The free Loss of the Cyber-Economy, in: CMC Magazin 1996. Redman, T.C.: The Impact of poor Data Quality on the Typical Enterprise, ACM Communications, 1998.

7.3 Generische Klassifizierungsansätze

181

x Accounting: Buchungsdaten und Buchungsbelege sowie Rechnungsabschlüsse wie Bilanz und Erfolgsrechnung. x Legal Records: Verträge und andere juristisch relevante Dokumente. Eine branchenorientierte Bewertung wird abgebildet, wenn die Bewertung der Daten gemäß SNIA mit der Data Protection Class kombiniert wird. So wird für jede Branche festgelegt, ob eine Datenkategorie wie beispielsweise die des Customer Service wichtig oder unwichtig ist. Die Daten werden einer der Kategorien von Not Important (Class 1) bis Mission Critical (Class 5) zugeordnet. Um eine Bewertung der Daten bezogen auf eine Branche zu erreichen, werden die Werte aus der Abbildung mit der fünfstufigen Klassifizierung hinterlegt. Die verfeinerte Bewertung ist ein Klassifizierungsversuch und hat nicht den Anspruch, empirisch belegte Werte zu erzeugen. Für die grundlegende Bewertung von Daten ist sie jedoch hilfreich und nützlich, da eine Firma, bzw. eine Branche die Wichtigkeit einer Datenkategorie festlegen kann und daraus direkt die Kosten für einen Datenverlust und damit den Wert der Daten, ableiten kann. Die

Abb. 7.7. Branchenorientierte Bewertung156



156

Die Autoren, SNW, a.a.O.

182

7 Schlüsselfaktor Klassifizierungskonzepte

Kosten beziehen sich auf die durchschnittlichen Kosten pro „Incident“ (d. h. pro Vorfall), falls die entsprechenden Daten verloren gehen oder nicht im definierten Zeitraum (RPO, Recovery Point Objective) wiederhergestellt werden können. Sie können als Indikatoren betrachtet werden, keinesfalls aber als absolute Werte in Euro. Durch eine Bewertung der Daten anhand ihrer Bedeutung für ein Unternehmen sind Aussagen bezüglich der Größenordnung der Kosten bei Datenverlust möglich. Die Summierung aller Kosten bei Datenverlust pro Datenkategorie ergibt eine Aussage über den Wert der Informationen für ein Unternehmen. Werden nun diese Werte der Servicequalität (SLO – Service Level Objective), die für die entsprechende Datenkategorie im Unternehmen definiert worden ist, gegenübergestellt, so kann ein Risikoportfolio der Unternehmensinformationen erstellt werden. Dabei wird der Abdeckungsgrad pro Datenkategorie bewertet und der SNIA-Klassifizierung gegenübergestellt.

7.3.1.5 Modell: Data-Protection-Initiative-Klassifizierung Die SNIA hat mit XAM (Extensible Access Method) eine klar strukturierte Klassifizierung definiert. Diese Klassifizierung wird mit Vorschriften zur Behandlung der einzelnen Datenklassen ergänzt. Dabei werden Kennzahlen für die Verfügbarkeit, den maximal zulässigen Datenverlust, die maximale Ausfallzeit und die maximale Offline-Zeit für die Datensicherung pro Klasse definiert. Die Kenngrößen der Klassifizierung sind: x RPO (Recovery Point Objective): Der Zeitraum zwischen zwei so genannten "Data Protection Events". Dies bedeutet, die maximale Menge der Daten, die verloren gehen dürfen. x RTO (Recovery Time Objective): Wie viel Zeit darf vergehen, bis ein System wiederhergestellt ist. x DPW (Data Protection Window): Der Zeitraum, der verwendet werden darf, um Daten zu sichern, während das System nicht online ist.

7.3.1.6 Modell: Datenverwaltungs-Dienstleistungen-Klassifizierung Die Kontrolle von Daten über ihren gesamten Lifecycle steht im Mittelpunkt der Klassifizierung auf Basis der Datenverwaltungsdienstleistungen. Sie umfassen die Dienstleistungen wie Datumsbewegung, Datumsredundanz und Datumslöschung. Bisher wurden die Daten pauschal bewertet und die Container (Informationsobjekte) bestimmt. Dieses Raster wird verfeinert, da sonst die höchste Anforderung auch auf Daten angewendet werden müsste, die nicht diese Anforderungen haben. Mit der Strukturierung der Daten teilen wir den gesamten Datenbestand in logisch zusammenhängende Teilbereiche auf. Die klassische und wohl auch einfachste Art der Strukturierung liegt in der Strukturierung nach Aufgabengebieten (oder auch Abteilungen). Beispiele sind Forschung, Entwicklung, Einkauf, Verkauf, Marketing oder Personalabteilung. Eine

7.3 Generische Klassifizierungsansätze

183

Datenstrukturierung kann auch nach Benutzergruppen erfolgen. Eine orthogonale Einteilung ergibt sich durch die Trennung von „strukturierten“ und „unstrukturierten“ Daten. Interessanter wird das Modell, wenn die vertikalen Verfahren einzelne Datenobjekte mit Attributen versehen können. Ideal wäre es, wenn z. B. ein Prozess im SMTP-Server bereits die Steuerrelevanz von eingehenden E-Mails bestimmen könnte.

7.3.1.7 Modell: Datumsklassifizierung Das Modell der Datumsklassifizierung findet meist dann Verwendung, wenn bezüglich des Information Lifecycle keine Informationen vorliegen. In solchen Fällen ist es sehr schwierig, zu entscheiden, welche Daten einer besonderen Stufe zugeordnet werden sollten.

7.3.1.8 Modell: Dienstleistungsklassifizierung Die Dienstleistungsklassifizierung wird durch Service Level Agreements (SLAs) und spezifische Policies beschrieben. SLA bezeichnet eine Vereinbarung, die Dienstleistungen durch genaue Beschreibung der zugesicherten Leistungseigen-

Abb. 7.8. SLA im Rahmen des Service Level Management157

 157

ITIL, SLA-Management und ISO 20000.

184

7 Schlüsselfaktor Klassifizierungskonzepte

schaften wie etwa der Reaktionszeit, Umfang oder Schnelligkeit transparenter zu gestalten. Wichtiger Bestandteil ist hierbei die Dienstgüte. SLAs legen fest, welche Leistung z. B. ein Endanwender erwarten kann, wenn er auf Informationsobjekte zugreift. SLAs sollten grundsätzlich für jede Leistungsbereitstellung definiert werden. In einem ILM gewinnt dieser Aspekt zusätzliche Bedeutung, da dynamische Prozesse aufgrund des sich verändernden Wertes der Informationen ablaufen. So können z. B. Informationsobjekte aus dem Online-Bereich auf langsamere, kostengünstigere Speichermedien verdrängt werden, wenn darauf längere Zeit nicht mehr zugegriffen wurde. Sollte auf die verdrängten Informationsobjekte wieder zugegriffen werden müssen, dann muss klar sein, dass der Zugriff länger dauern wird, aber eine bestimmte maximale Zeit nicht überschritten werden darf. Aufgrund der SLA-Festlegungen im Rahmen des Service Level Management (SLM) ergibt sich die Technologie, auf die die Informationsobjekte gemäß den jeweiligen Zeiträumen verdrängt werden können. Die wesentlichen Inhalte eines SLA bestimmen sich auf Basis von ISO 20000 und ITIL.

Abb. 7.9. Klassifizierung mit dem Fokus Verfügbarkeit im Rahmen eines Business-Continuity-Plans158

 158

Die Autoren, SNW, a.a.O.

7.3 Generische Klassifizierungsansätze

185

7.3.1.9 Modell: Disaster-Recovery-Klassifizierung Es gibt Unternehmen, deren wichtigste Herausforderung aus IT-Sicht die Vermeidung des Katastrophenfalls ist, auch als Desaster-Fall bezeichnet. Hier hat die Bereitstellung der Daten ohne jeden Datenverlust („data loss“) und ohne wirkliche Ausfallzeit primäre Bedeutung. Zentrales Instrument ist hier der Business-Continuity-Plan, in dem das Datenspeichersystem die entscheidende Rolle spielt. Die Klassifizierung erfolgt hier gem. den spezifischen Anforderungen in Verbindung mit den speziellen Eigenschaften der Speichermedien.

7.3.1.10 Modell: Geschäftsfeldklassifizierung Die Perspektive der Geschäftsfeldklassifizierung ist die Anwendungsebene. Das Modell umfasst die Umwandlung der Geschäftsklassifizierungen zu verkäuferneutralen Dienstleistungsklassifizierungen. Dieses Modell der Klassifizierung muss die Einhaltung branchenspezifischer technischer und nichttechnischer Anforderungen abdecken, wie z. B. den Besitz, bzw. die Zuteilung von Hilfsmitteln. Die Geschäftsfeldklassifizierung kann spezifische Dienstleistungsklassifizierungen integrieren.

7.3.1.11 Modell: Informationsmanagement-Dienstleistungen-Klassifizierung Die Informationsmanagement-Dienstleistungen-Klassifizierung betrachtet die Prozesse, die Auskunft und die Aufzeichnungen durch verschiedene, sich gemäß dem Geschäftsprozess ergebende Verbindungen zwischen Unternehmen und deren Steuerung. Diese Dienstleistung kann benutzt werden, um die Beauskunftung, Metadaten, Datenverwaltungsdienstleistungen oder die Nutzung der Infrastrukturen zu der Durchführung der spezifischen „Policy“ bereitzustellen. Genutzt wird das Modell z. B. beim Aufzeichnungsmanagement.

7.3.1.12 Modell: Metadatumsklassifizierung Metadatumsklassifizierungsverfahren werden genutzt, um Datumsbewegungen über verschiedene Stufen der Speicherung zu planen. Als Metadaten oder Metainformationen bezeichnet man allgemein Daten, die Informationen über andere Daten enthalten. Bei den beschriebenen Daten handelt es sich oft um größere Datensammlungen (Dokumente) wie Datenbanken oder Dateien. So werden auch Angaben von Eigenschaften eines Objektes als Metadaten bezeichnet. Während der Begriff „Metadaten“ relativ neu ist, ist das Prinzip unter anderem eine jahrhundertealte, bibliothekarische Praxis.

7.3.1.13 Modell: IT-Sicherheitsbasierte Klassifizierung Mit den Veränderungen in der Speicherlandschaft hat die Frage nach der ITSicherheit eine neue Facette erhalten. In dem Maße, wie Unternehmen die

186

7 Schlüsselfaktor Klassifizierungskonzepte

Datenspeicher vernetzen, nimmt die Notwendigkeit zu, Speichernetze gegen Missbrauch zu schützen. Analog zum Wert der Daten müssen deshalb die Zugriffsrechte prinzipiell aus unternehmerischer Sicht definiert werden. Beispielsweise ist zu entscheiden, ob Daten nur intern oder auch extern zugänglich sein sollen. In der Praxis existieren natürlich zuerst einmal intern unterschiedliche Benutzergruppen mit unterschiedlichen Zugriffsrechten. Diesen Vorgaben muss ILM Rechnung tragen, so dass diese durch die ILM-Aktionen nicht verletzt werden. Nach einer Verdrängung müssen z. B. zuerst einmal dieselben Zugriffsrechte weiter bestehen wie vor der Verdrängung. Das Gleiche gilt für Backup, Replikation, Archivierung etc. Schutzanforderungen können sich im Lebenszyklus verändern. Unternehmerische Vorgaben müssen auch festlegen, für welche Datenbereiche absolute Datenintegrität gefordert wird. Datenintegrität bedeutet, dass Veränderungen in jeglicher Form ausgeschlossen werden. Die neuen Plattentechnologien können u. a. dazu genutzt werden, um das Sicherheitsparadigma zu vergrößern. Die eingesetzten Technologien umfassen die Speicherung von Snapshots (Momentaufnahmen), Vollkopien von Momentaufnahmen (Spiegel), differentiale Momentaufnahmen und Serial Attached SCSI (SAS) ebenso wie kontinuierlicher Datenschutz (CDP, Continous Data Protection) in seinen verschiedenen Formen. Teilweise werden auch verschiedene Technologien kombiniert. Ein wichtiger Punkt für Integratoren ist, dass es erstmals möglich wird, SAS- und SATA-Festplatten in einem Gehäuse zu kombinieren. Dies erlaubt den Bau von Systemen, die einerseits höchste Zuverlässigkeit und Geschwindigkeit bei SAS und andererseits schnelle Geschwindigkeit bei einem günstigen Verhältnis von Kosten pro GByte wie bei SATA vereinen. Die Technologien umfassen auch das SAN-Sicherstellungsparadigma, Bandbibliotheken, die mit normalem SCSI die Bandlaufwerkausführung teilen, Platteninszenierungen mit normaler Platte und virtuellem Band sowie Momentaufnahmen und Erweiterung.

7.3.1.14 Modell: Standardbasierte Klassifizierung Mit dem XAM-Vorschlag der SNIA existiert ein Industrievorschlag zur Schaffung standardmäßiger Schnittstellen, um Metadaten zwischen Anwendungen und Lagerungssystemen zu koordinieren. Weitere Standardisierungsbestrebungen gibt es aktuell nicht. De-facto-Standards gibt es wohl im Bereich einzelner Applikationen und Technologien. Eine Klassifizierung der Daten auf Basis von De-facto-Standards kann eine langfristig sinnvolle Klassifizierungsstrategie sowohl im Hinblick auf die Optimierung des TCO als auch des langfristigen Investitionsschutzes darstellen.

7.3.1.15 Modell: Value-driven-Klassifizierung Die Festlegung des Werts der Informationen muss als unternehmerische Vorgabe erfolgen. Die Basis liegt in den betriebswirtschaftlichen Geschäftsprozessen mit der Abbildung der Geschäftslogik. Oft wird man feststellen, dass die Geschäftprozesse nicht hinreichend klar definiert sind. Wenn einmal der Wert der

7.3 Generische Klassifizierungsansätze

187

Informationen definiert ist, kann auch der Schutz der Informationen konkretisiert werden. Die wichtigsten Überlegungen sind, welche Anforderungen z. B. an RPO (Recovery Point Objective) und RTO (Recovery Time Objective) gestellt werden. In bestimmten Branchen ist dies nicht alleine eine interne Entscheidung, sondern wird durch Verbandsvorgaben oder sogar durch Gesetze beeinflusst. Als Grundgedanke liegt dem Konzept zugrunde, dass sich der Wert der meisten Informationen und damit das Zugriffsmuster auf deren Informationsobjekte im Laufe der Zeit verändern. Über automatisierte Prozesse wird sichergestellt, dass die Informationsobjekte zu jeder Zeit am richtigen Ort mit den geringst möglichen Kosten gespeichert werden. Damit reduzieren sich die Investitionskosten. Hardwarekosten sind jedoch nur ein kleiner Teil der Gesamtkosten. Unterschiedliche Total Cost of Ownership (TCO-) Betrachtungen gehen davon aus, dass dieser Teil nur ein Drittel bis ein Fünftel ausmacht. Die restlichen Kosten sind Infrastruktur-, Administrations- und Betriebskosten. Eine rechtzeitige Archivierung von Informationsobjekten entlastet z. B. den Online-Bereich, für den aufwendige Datensicherungsprozesse ablaufen. Archivierte Informationsobjekte bzw. verdrängte Informationsobjekte brauchen im Prinzip nur einmal gesichert zu werden. Durch Archivierung kann somit das tägliche, wöchentliche oder monatliche Datensicherungsvolumen reduziert werden. Noch gravierender ist dies im Bereich der Wiederherstellung. Falls der Online-Bereich nicht von alten Informationsobjekten entlastet ist, müssen alle Objekte erst zurückgeladen werden, bevor die Anwendung wieder online gehen kann.

7.3.1.16 Modell: XAM-Klassifizierung Mit dem SNIA-Standard Extensible Access Method (XAM) sollen Speicherregelwerke über Anwendungsgrenzen hinweg ermöglicht werden. XAM ist ein Industrievorschlag zur Schaffung standardmäßiger Schnittstellen, um Auskunftsmetadaten zwischen Anwendungen und Lagerungssystemen zu koordinieren. Das XAM-Projekt startete im Oktober 2004 als ein Gemeinschaftsunternehmen von IBM, EMC, HP, Hitachi und Sun Microsystems. Der vorgeschlagene Standard wurde SNIA im letzten September präsentiert. XAM schafft laut SNIA eine enge Verzahnung zwischen Anwendung und Speichermedium. Dadurch kann das Speichersystem Metadaten bezüglich Informationen, Daten und Sicherheit zu den einzelnen zu speichernden Daten in Beziehung setzen. Dies wiederum ermöglicht die Formulierung von Regeln bezüglich des Speicherorts, der Haltedauer, des Datenschutzes, der Datenverteilung, der Verschiebung und Migration von Daten, ihrer Sicherheit, der nötigen Authentifizierung und so weiter. Das von SNIA entwickelte XAM-Interface soll die Entwicklung vereinfachen, indem durch das Zuweisen „standardmäßiger“ Metadaten, die Informationen auf unterschiedlichen Wegen als aktiv oder sich ändernd gelagert werden können. Diese Metadaten und eine standardmäßige Schnittstelle sind Schlüssel dazu, mit ObjectServices zu kommunizieren (OSD) und Auskunftsklassifizierung, langfristige Aufzeichnungszurückhaltung und Auskunftssicherheit zu automatisieren. Mit

188

7 Schlüsselfaktor Klassifizierungskonzepte

der langen Speicherfähigkeit von festem Content und der zunehmenden Menge von sich verbindenden Vorschriften wird die XAM-Schnittstelle einen selbstbeschreibenden Weg eröffnen, Informationen zu bewahren, und es Anwendungen und Aufzeichnungen ermöglichen, über und zwischen Speichersystemen und Anwendungen zu wandern. Zusätzliche XAM-Arbeitsbereiche innerhalb SNIA und hier innerhalb des Datenverwaltungsforums sind der XAM-Schnittstelle gewidmet. SNIA plant die Definition einer Softwareentwicklungs- und Prüfungskonzeption (QS), ein Verweismodell für die Verwendung und die schnelle Annahme sowie ein Sicherheitsmodell. Insbesondere die Aspekte Security und QS halten die Autoren für so wichtig, dass sie diesen Aspekt gesondert behandeln. „XAM ist somit eine wichtige Entwicklung für Fixed-Content-AwareSpeichersysteme und ILM-Automatisierung. Der Standard fördert eine engere Integration zwischen unterschiedlichen Datentypen und -gruppen, so dass ITund Storage-Verantwortliche Informationen effektiver managen können“, sagt Paul Talbut, Chairman der SNIA Europe. „Die SNIA Europe bietet bereits Hintergrundmaterial zu XAM. Wir wollen Endkunden, Hersteller und Integratoren dazu bewegen, sich darüber zu informieren, wie sie von der Entwicklung dieser neuen Storage-Schnittstelle profitieren können“, erläutert Talbut. Da die XAM-Schicht zwischen Anwendung und Speicher liegt, schafft sie damit eine bislang fehlende Voraussetzung für anwendungsübergreifende ILMSysteme, wie sie die SNIA-ILM-Pyramide auf Ebene 4 und 5 vorsieht. Kundenspezifische Anwendungsschnittstellen verlieren damit ihren Schrecken, sie bleiben für das Speichersystem unsichtbar. Damit erfüllt XAM ähnliche Funktionen wie heutige SAN-Filesysteme. ILM, die Speicherung unstrukturierter Daten, aber auch Grid-Computing dürften davon profitieren. Die Industriestandardschnittstelle XAM soll auch dafür sorgen, dass Aufbewahrungsorte und Fristen eingehalten werden. Diese Vorstellung wird eine Übersicht über die Anforderungen für die Bewältigung des festen Contents geben. Insbesondere die Planer und Lösungsentwickler, die für Archivlösungen zuständig sind, benötigen die Einhaltung spezifischer Standards. Erst XAM sorgt für eine Übersicht über die sich ergebenden Probleme mit der Sicherstellung der logischen Lesbarkeit im langfristigen Archiv. Die Erfolgsaussicht von XAM muss aktuell noch skeptisch beurteilt werden. Insbesondere Microsoft ist kein Teilnehmer des Standardisierungsgremiums. Microsoft ist aber gerade in kleineren Firmen der Hauptdokumentenlieferant und dürfte weniger auf XAM als auf XML (Extensible Markup Language) setzen, also eine Vereinheitlichung schon auf Ebene des Dokumentenformats. Zudem kündigen Firmen wie CA und Symantec Pre-Certified-XAM-Produkte an, bei denen es bei einer Normung erhebliche Änderungen geben müsste, damit sie die mögliche Norm erfüllen. Das Aperi-Forum möchte eine offene Speichermanagementplattform (Open Source) entwickeln, die dann auch ILM-Komponenten enthalten dürfte. Die neue Industrieassoziation besteht aus Unternehmen wie IBM, Cisco, Computer Associates, Engenio, McData und Network Appliance, die dazu Code beisteuern wollen. Mit EMC, HP, Hitachi Data Systems und Symantec fehlen aber sehr wichtige Hersteller.

7.3 Generische Klassifizierungsansätze

189

Für XAM spricht, dass insbesondere große Anwenderunternehmen massiv von den Vereinheitlichungseffekten des SNIA-Standards profitieren könnten. Daher dürften SNIA-Standards in Lösungen wie der geplanten Aperi-Plattform einfließen. Und so steht die Chance nicht schlecht, dass die zukünftigen ILMStrategien wesentliche Teile von XAM umsetzen werden. ILM wird somit auf jeden Fall von den Arbeiten an XAM profitieren. SNIA sieht durch die XAMSpezifikation auch eine langfristige Weichenstellung für den Endbenutzer.

7.3.2 Dynamisches Klassifizierungsmodell Datenklassifizierung und „Tiered“-Speichertechnologien sind aber noch nicht der Weisheit letzter Schluss, weil es sich dabei um statische Lösungen handelt. Es kann notwendig sein, Informationen dynamisch zwischen den Speicherebenen zu verschieben. Die abgewickelte Bestellung eines Kunden muss nicht unbedingt zwei Jahre lang auf den teuren Online-Systemen verfügbar sein und dort unnötig Speicherplatz belegen. Nach definierter Zeit verschieben dynamische Systeme solche Daten z. B. auf ein Worm-System und archivieren sie dort wesentlich kostengünstiger. Sowohl für die IT-Administratoren als auch für die Anwender ist das Thema dynamische Anpassung der Klassifizierung und damit der Speicherung der Daten zu komplex und kann allein aufgrund der Masse an Daten im Unternehmen nicht manuell erledigt werden. Für die kontinuierliche Klassifizierung der Dokumente eignen sich beispielsweise DMS/ECM-Systeme, Filesystem-Archivierung (HSM, Hierarchical Storage Management), E-Mail-Anwendungen und Datenbanken. Entscheidend ist das Verständnis für die Prozesse im Unternehmen und wie sich diese auf die Informationen auswirken und vice versa. Wenn beispielsweise die Forschung im Labor ein Dokument erstellt, kann dies in verschiedenen Prozessen eine wichtige Rolle spielen. Die Information kann in der Folge ein Teil eines Patentantrags, einer Studie oder eines Antrags für Drittmittel sein. Damit überschreitet die gespeicherte Information viele Grenzen innerhalb und außerhalb des Unternehmens. Dynamische Klassifizierung erfordert, dass die Daten schon bei der Erstellung den Prozessen zugeordnet werden. Unterschiedlichste Systeme wie Publishing Engines, Applikationen für Studien sowie Vertriebs- und MarketingPortale müssen damit interagieren. Wenn die Inhalte schon bei ihrer Erstellung bestimmten Prozessen zugeordnet werden, kann eine Auswirkungsanalyse schon frühzeitig die Lebensphasen einer Information und ihre voraussichtlichen Anforderungen an den Speicherort aufdecken. Dies hängt beispielsweise davon ab, ob sie später archiviert werden muss oder nach Beendigung des letzten Prozesses gelöscht werden kann. Diese Informationen werden, neben Basisangaben wie Erstellungsdatum und Quelle, in den Metadaten gespeichert. Ein weiterer Vorteil ist, dass der Content später über die Metadaten sehr viel einfacher wieder aufzufinden ist. Natürlich kann dies nicht nach einem statischen Schema ablaufen, in dem genau die Zeitpunkte und Migrationsstufen vorgegeben sind. Das System muss eigenständig den Status der Informationen im Rahmen der

190

7 Schlüsselfaktor Klassifizierungskonzepte

zugeordneten Prozesse analysieren und sie den entsprechenden Informationsklassen zuordnen. Ändert sich die Klassifizierung, und damit auch die nötigen Servicelevels, müssen die Daten innerhalb der Infrastruktur migriert werden. Auch dies sollte mittels intelligenter Managementsoftware automatisiert ablaufen. Dazu werden in einem Regelwerk die Speicherebenen und ihre Servicelevels in Bezug gesetzt. So muss das System eigenständig ermitteln, ob die Daten korrekt abgelegt sind, und sie gegebenenfalls verschieben. Voraussetzung für eine solche dynamische Informationsverwaltung ist eine einheitliche Managementumgebung für die gesamte Speicherinfrastruktur mit allen Speichersystemen und Netzkomponenten im SAN- und NAS-Bereich. Sie muss in der Lage sein, die Daten ohne Auswirkungen auf die Applikationen zwischen den Speicherebenen zu verschieben. Das gelingt mit Virtualisierungslösungen, die die physikalische von der logischen Speicherebene trennen.

7.4 Tiered Storage als Lösungsinstrument bei der operativen Umsetzung der Klassifizierung ILM kann umso wirksamer arbeiten, je besser der gesamte Speicherbereich strukturiert ist. Dies erfolgt üblicherweise über Speicherhierarchien und Speicherklassen. Speicherhierarchien ergeben sich in der Klassifizierung von Speichertechnologien nach technischen oder nach Kostengesichtspunkten in einer absteigenden bzw. aufsteigenden Ordnung. Technische Aspekte und Kostengesichtspunkte sind oft voneinander abhängig. So sind z. B. Speichersysteme mit schnellem Zugriff in einer höheren Preisklasse angesiedelt als Speichersysteme mit langsamerem Zugriff. Speicherklassen ergeben sich aus der logischen Strukturierung des Speicherbereichs. Somit können Speicherhierarchien noch feiner strukturiert werden. Darüber hinaus kann z. B. nach Anzahl der automatisch zu erzeugenden Kopien von Informationsobjekten differenziert werden, auch wenn die Speicherobjekte in derselben Speicherhierarchie liegen. Aufsetzend auf den durch Klassifizierung ermittelten Anforderungen wird eine „Tiered“-Storage-Architektur abgeleitet. Das Spektrum des Tiered Storage reicht von hochverfügbaren Umgebungen für kritische Produktionsdaten, die zusätzlich an einen zweiten Standort gespiegelt werden, über Online-Archive bis hin zu Bandrobotern für die Datensicherung und -archivierung. Dazwischen lassen sich vielfältige Zwischenstufen einrichten, um die Serviceziele für Anwendungsdaten wie E-Mail oder Datenbank zu erreichen. Beim „Tiered“-Speicher können beispielsweise die Informationen in drei Verfügbarkeitsklassen eingeteilt werden. x Klasse 3 ist z. B. für die Speicherung und Sicherung weniger wichtiger Daten wie Home Directories oder das SAP-Testsystem vorgesehen und besteht aus Midrange-Systemen mit FC-Platten (Fibre Channel).

7.4 Tiered Storage als Lösungsinstrument bei der operativen Umsetzung der Klassifizierung

191

x Klasse 2 bietet z. B. die Standard-Speicher-Performance ebenfalls auf Basis der Mittelklassespeicher mit FC-Technologie, allerdings mit einer zusätzlichen Spiegelung. x Klasse 1 ist für unternehmenskritische Informationen reserviert. Die kritischen, produktiven Daten der Klasse 1 lagern auf hochperformanten, gespiegelten Highend-Systemen. Unveränderliche Daten, die nicht mehr aktiv benötigt werden, werden z. B. in ein Online-Langzeitarchiv mit ATA-Platten und Worm-Funktionalität verlagert. Es gilt dabei generell der folgende Grundsatz für die Verlagerung: Je wichtiger die Daten für ein Unternehmen sind, desto höher sollte ihre Verfügbarkeit sein. Leider besteht auch der folgende Zusammenhang: Je höher die Verfügbarkeit, desto teuerer sind die geeigneten Speichermedien. Für die Einrichtung der Speicherebenen können Technologien wie Storage Area Network (SAN), Network Attached Storage (NAS) oder Content Addressed Storage (CAS) innerhalb eines Speichernetzes auch kombiniert werden. Einige Hersteller bieten mittlerweile sogar innerhalb eines Systems verschiedene Speicherklassen an. So können beispielsweise in einem Array leistungsfähige und teure Fibre Channel (FC-) connected Festplatten mit günstigeren ATA-Laufwerken kombiniert werden. Und selbst innerhalb der FC-Anbindungstechnik gibt es mittlerweile unterschiedliche Varianten, so dass auch im Highend-Bereich eine Abstufung möglich ist, wie sie EDS vorschlägt. Ist der tatsächliche Wert der Informationen bekannt, lassen sich die Speicherinvestitionen dementsprechend planen und die Gesamtkosten senken. Die Vorteile von Tiered Storage lassen sich auch im Archiv nutzen. Wenn Transaktionsspeicher und Backup-Umgebung von allen unveränderlichen Daten entlastet werden und diese in ein sich selbst verwaltendes Langzeitarchiv, basierend beispielsweise auf CAS, verlagert werden, vereinfacht dies den Backup-Prozess signifikant und senkt zusätzlich den Verwaltungsaufwand deutlich.

8 Schlüsselfaktor IT-Sicherheit

Die zukünftige, wachsende Bedeutung der IT-Sicherheit für das Geschäft mit Speicher und ILM zeigt am besten die folgende Pressemitteilung anlässlich der Übernahme von RSA durch EMC, für die EMC in 2006 die hohe Summe von 2,1 Mrd. US $ zahlte. „RSA’s identity management, access management, and data encryption products will be the heart of EMC’s „information-centric security strategy“, CEO Joe Tucci said in a statement. Network Intelligence’s wares will allow EMC to offer customers compliance and security policy management tools as part of that strategy.“159 Nicht zuletzt zeigt die Analyse der IT-Sicherheitsvorfälle erschreckende Ergebnisse. 50 Prozent der Top-10-Datendiebstähle in Bezug auf Datenmanagement betreffen Backup-Medien. Die durchschnittliche Anzahl der Datensätze beträgt dabei über 430.000 und liegt damit fast 200 Prozent über den anderer Medien. Innerhalb des letzten Jahres waren über 50 Mio. Datensätze betroffen.160 Die heute noch vorherrschende geringe Wertschätzung der eigenen Daten dokumentieren die beschriebenen Beispiele. Auch in Deutschland wird der Wert der Information häufig verkannt. Auch hier soll dies ein Beispiel aus dem Bereich Banken verdeutlichen. Eine Bank erstellt wöchentlich ein Backup, ohne dieses auch regelmäßig auf seine Eignung zu überprüfen. Die Sicherung wird auch regelmäßig von einer Sicherheitsfirma abgeholt und in deren Aufbewahrungsräumen deponiert. Wer den aktuell stark ramponierten Ruf dieser Branche im Hinterkopf hat, der wundert sich, dass das Backup weder verschlüsselt wird, noch werden Vorkehrungen getroffen zumindest das unbemerkte Lesen und Kopieren der Daten zu verhindern oder durch Versiegelung erkennbar zu machen. Auch beim Rücklauf der Bänder nach Ablauf der Aufbewahrungsfrist findet keine Kontrolle statt, ob die Bänder im Extremfall etwa von Dritten manipuliert wurden.

8.1 Datensicherheit In einem Unternehmensnetzwerk übernimmt den Schutz vor einem Eindringling von außen eine Firewall und die Funktion des Warnsystems ein Intrusion Detection System (IDS). Ist dies heute der Stand in vielen Unternehmen, Behörden  159 160

EMC-Pressemitteilung, 2006, www.emc.com. Messeausgabe DMS-Köln 2006.

194

8 Schlüsselfaktor IT-Sicherheit

und anderen Organisationen im Zusammenhang mit der Netzwerk- und Datensicherheit? Eine Firewall gegen Einbruch ist vielleicht installiert, jedoch häufig wegen unzureichender Administration und Überprüfung meist löchrig wie der bekannte Schweizer Käse. Die Sicherheitssoftware Firewall kann das Problem eines Datenmissbrauchs oder Datendiebstahls nicht wirklich lösen; sie zeigt nur, wie schwach und verletzbar Computersysteme und -netze sind. Auch ein gut geschütztes Netz ist Angriffen ausgesetzt. Angriffe von innen, entweder durch einen infizierten PC oder Notebook oder gar böswillige Mitarbeiter, laufen zudem nicht über die Firewall und können von ihr auch nicht verhindert werden. Ein Intrusion Detection System (IDS) hat hier die Aufgabe, die Administratoren bei der Erkennung von Angriffen zu unterstützen. Ein solches IDS ist jedoch in den wenigsten Fällen vorhanden. Die Daten liegen meist ungeschützt auf den Servern und Arbeitsplatzrechnern der Mitarbeiter. Hierdurch gefährdet ein Unternehmen nicht nur potenziell die Sicherheit seiner digitalen Daten, welche in unserer zunehmend digitalisierten Welt für jedes Unternehmen zum wichtigsten und wertvollsten Gut geworden sind, sondern es verstößt hierdurch häufig auch potenziell gegen gesetzliche Auflagen bezüglich des Datenschutzes. Optimaler Schutz und ständige Verfügbarkeit entscheiden oftmals über den Fortbestand des Unternehmens. Diese Tatsache spiegelt sich mittlerweile in den immer komplexer werdenden gesetzlichen Anforderungen gegenüber den Betrieben wieder, die für den Schutz ihrer Daten eigene Sicherheitskonzepte entwickeln und umsetzen müssen. Hackerangriffe auf Speichersysteme können teuer werden – und die Behebung des Schadens kostet zudem viel Zeit. Vermeiden kann man solche Probleme, wenn man Speicher im Netzwerk ausreichend absichert. Dabei stellen nicht nur Einbrüche von außen ein Risiko dar. Gefahr für die Daten entstehen sowohl durch Missbrauch von außer- als auch von innerhalb des Unternehmens. Studien belegen, dass die meisten Unternehmen autorisierte, nichtautorisierte und ehemalige Mitarbeiter als Hauptverdächtige für das Begehen von Informationsverbrechen betrachten. Insbesondere mit den Veränderungen bei den Speichermedien und deren Vernetzung hat die Frage nach der IT-Sicherheit eine neue Facette erhalten. Der Trend zu immer sichereren Netzen ist das Ergebnis einer Reihe von gesetzlichen und regulativen Verordnungen (wie bereits beschrieben). So stammt beispielsweise die Richtlinie Basel II aus der Finanzwelt und betrifft bei der Kreditbeschaffung nahezu alle Unternehmen. Diese müssen nämlich zur Erzielung eines guten Ratings und für die Erlangung günstigerer Kredite gegenüber den Banken nachweisen, dass sie unter anderem ein funktionierendes operatives Risikomanagement besitzen. Dazu gehört neben der schnellen Wiederherstellung der IT im Katastrophenfall auch die Robustheit gegen Sicherheitsverletzungen von innen und außen sowie die Sicherung und Sicherheit von Unternehmensdaten. Entsprechend hoch ist für Unternehmen die Bedeutung von Speichersicherheit einzuschätzen. Sicherheit im SAN- und NAS-Umfeld mit dezentraler Datenhaltung und offenem Zugriff unterscheidet sich nicht grundsätzlich von den Sicherheitstechnologien in anderen Netzen. Jahrzehntelange Erfahrungen aus dem LAN- und WAN-

8.2 IT-Speichersicherheit

195

Bereich konnten hier einfließen, und so setzt die Speicherindustrie zunehmend auf die gleichen Sicherheitsprotokolle wie IPsec (IP-Layer-Security), SSL (Secure-Sockets-Layer), TLS (Transport-Layer-Security), SSH (Secure-Shell) und PKI (Public-Key-Infrastructure). Ergänzt werden diese Standards noch durch das Fibre-Channel-spezifische Security-Protokoll (FC-SP, ANSI/T 11.3), das vom Standardisierungsgremium im Juni 2004 verabschiedet wurde. In dem Maße, wie Unternehmen die Datenspeicher vernetzen, nimmt die Notwendigkeit deutlich weiter zu, Speichermedien, Speichernetze und Backups gegen Missbrauch zu schützen. Moderne SAN- und NAS-Speichernetze sowohl auf Basis von Fibre Channel (FC) und iSCSI verfügen lediglich über unvollständige Sicherheitsmechanismen und entsprechen nur selten der unternehmensweiten IT-SecurityPolicy. In FC-SANs werden Verfahren wie das Zoning und LUN (Logical Unit Number)-Masking eingesetzt, um funktionale und sicherheitsrelevante Anforderungen zu erfüllen. Für iSCSI-SANs kommt das bekannte IPsec zur Anwendung. Es beinhaltet unter anderem die Authentifizierung der Originalverbindungen und die Verschlüsselung von Daten während der Übertragung. Aus Sicht des amerikanischen Instituts der Wirtschaftsprüfer (AICPA) reicht es nicht aus, eine sichere Speicherarchitektur sozusagen „alone“ zu entwerfen. „Die Mehrheit von Sicherheitsvorfällen hat innerbetriebliche Gründe.“161 Laut Munroe (Chief Operating Officer) nützen IT-Sicherheitsarchitekturen nicht viel, wenn ein Kennwortproblem existiert oder wenn das Personal nicht trainiert wurde Verfahrensfestlegungen zu folgen. Seine Empfehlung lautet: „Führe routinemäßige Sicherstellungen von deinem Betriebssystem, Programmen, Anwendungen und allen Dateien durch. Ohne Datensicherung erholen sich die meisten Geschäfte niemals völlig von Datumsverlust. Vergewissere dich dessen, dass das Personal fähig ist, performante Sicherungen durchzuführen.“162 ISO 17799 fordert, für jedes der identifizierten Risiken eine Risikobehandlungs-Entscheidung zu treffen. Die Wahlmöglichkeiten schließen ein: x Angemessene Kontrollen anzuwenden, um die Risiken zu reduzieren, x Wissentlich und objektive Risiken zu akzeptieren, x Risiken zu vermeiden, d. h. keine Aktionen erlauben, die Risiken verursachen würden oder x die vorhandenen Risiken auf andere Parteien zu übertragen, z. B. auf Versicherer oder Lieferanten.

8.2 IT-Speichersicherheit 8.2.1 Anforderungen IT-Speichersicherheit beschreibt ein Sammelsurium an Sicherheitsschlössern und Einstellungen, die verhindern sollen, dass unautorisierte Benutzer zu den  161 162

CISA, www.isaca.org/cisa. AICPA, www.aicpa.org.

196

8 Schlüsselfaktor IT-Sicherheit

Ressourcen vordringen und im Gegenzug berechtigte User über gesicherte Kommunikationskanäle einen Zugriff auf die gespeicherten Daten haben. Im Grunde fallen die gleichen Begriffe wie im klassischen IT-Sicherheitssektor. Die Eckpfeiler der IT-Speichersicherheit sind: x x x x x x x

Authentifizierung, Autorisierung (Zugriffskontrolle), Accounting/Auditing, Reporting (Wie lange war wer wo drin?), Datenintegrität (Compliance, Einhaltung von Regeln), Vertraulichkeit und Verschlüsselung.

Die Authentifizierung prüft, ob es sich um einen bekannten und zugelassenen Administrator oder Anwender handelt. Hier greifen Technologien wie Passwortschutz, Zertifikate oder biometrische Überprüfungen. Autorisierung geht noch einen Schritt weiter. Neben der Überprüfung der gültigen Berechtigung werden auf Objektebene verschiedene Rechte vergeben. So darf etwa ein Administrator die Zonen des Switches umkonfigurieren, während ein anderer nur bestimmte Performance-Reports drucken kann. Accounting und Auditing zeichnen alle Managementaktivitäten historisch auf und werten sie aus. Dies dient vor allem dem lückenlosen Nachweis aller Zugriffe auf die Speicherkomponenten im SAN und ist in vielen Industriezweigen heute zu einer wichtigen Sicherheits- und Compliance-Anforderung geworden. Reporting stellt die aufgezeichneten Aktivitäten gemäß den jeweiligen spezifischen Anforderungen zusammen und macht sie für die IT-Sicherheitsadministratoren erst lesbar. Datenintegrität bedeutet den Nachweis, dass Daten unverfälscht übertragen und abgespeichert werden. Dies hat relativ wenig mit dem stets identischen CRC-Prüfverfahren auf Netzebene zu tun, welches lediglich die fehlerfreie Datenkommunikation sicherstellt. Hier dagegen wird die Sicherheit mittels eines sicheren Hash-Algorithmus wie MD5 nach dem Austausch von privaten und öffentlichen Sicherheitsschlüsseln gewährleistet. Vertraulichkeit wird durch diverse Verschlüsselungsverfahren wie DES, Triple-DES, AES oder Blowfish garantiert. Nur Sender und Empfänger, die im Besitz der Private- und Public-Keys sind, können die übertragenen Daten entschlüsseln und verstehen. Neben der Sicherheit der Informationsübertragung stellt sich zunehmend die Forderung, spezifische Information generell nur verschlüsselt zu speichern und insbesondere nur verschlüsselt im Backup-Modus zu behandeln. Von den weltweit ca. 10 TB Backup werden bereits heute 10 Prozent verschlüsselt gesichert, d. h. aktuell sind ca. 1 TB Backup-Daten verschlüsselt mit steigender Tendenz.163 Trotz der Gemeinsamkeit mit den klassischen IT-Sicherheitsansätzen gibt es doch Unterschiede in der grundsätzlichen Philosophie. IT-Sicherheit war und ist immer geprägt von Abschottung. Speicherung hat als zentrales Ziel die Erfüllung der Grundanforderung der stetigen Verfügbarkeit von Information. Die  163

Messeausgabe DMS-Köln, 2006, a.a.O.

8.2 IT-Speichersicherheit

197

neuen Gesetze, allen voran die Compliance-Regeln, zwingen die Unternehmen auf der einen Seite, ihre Daten über viele Jahre unverändert aufzubewahren, auf der anderen Seite fordern gesetzliche Bestimmungen, dass auch ältere Daten mit der aktuellen IT lesbar sind. Ist dieses nicht gewährleistet, so drohen auch hier Strafen. Wie eng das Verhältnis werden kann, haben Veritas und Symantec durch ihre Fusion gezeigt. Sicherheit bedeutet heute auch Verfügbarkeit. Der Zugriff auf Daten muss schnell möglich sein. Dies ist nur möglich, wenn eine Horde Unberechtigter daran gehindert wird, Viren einzuschleusen und Angriffe gegen das Speichernetz durchzuführen. John W. Thompson, Symantecs Chairman und CEO, sagte nach der angekündigten Fusion: „Die neue Symantec will Anwendern helfen, die Balance zwischen der Sicherheit der Informationen und ihrer Verfügbarkeit zu schaffen.“164 Nur mit Datenintegrität kann ein Unternehmen kosteneffektiv arbeiten und das Geschäft profitabel weiterführen. Diese strategische Herausforderung dürfte wohl der Beweggrund hinter dem Kauf von RSA durch EMC sein.

8.2.2 Problembeschreibung IT-Speichersicherheit In der Vergangenheit war Speicher physikalisch und logisch isoliert. Es wurde auf DAS (Direct Attached Storage) gesichert. Nur derjenige, der von seinem Rechner aus speicherte, griff auch wieder auf die Daten zu. Diese Art der Datensicherung wird zunehmend aufgrund der wachsenden Datenpräsenz ineffizient. NAS (Network Attached Storage) und schließlich SAN (Storage Area Network) mit dem Fibre-Channel-Protokoll (FC) ersetzten schnell die traditionellen Konzepte. Die Gefahr von Angriffen aus dem weltweiten Netz blieb gerade mit FC noch gering. Der Grund ist banal. Das FC-Protokoll ist weniger bekannt und durchschaubar als das IP-Protokoll. In den letzten Jahren kamen gerade im WANBereich (Wide Area Network) auch IP-basierte Speichernetzwerke zum Einsatz. Das hier verwendete Internetprotokoll (IP) ist den Angreifern meist in allen Details bekannt. Jede Schwachstelle ausreichend beschrieben und in den einschlägigen Kreisen „beliebt“. Leider spüren das auch die auf Speichernetze und IP gleicher Maßen konzentrierten neuen Protokolle wie iSCSI oder FCIP. Sie nutzen die Vorteile von IP, versenden Befehle getunnelt über das klassische Protokoll und können so große Distanzen überbrücken, um Rechenzentren in geografisch verteilten Standorten zu erreichen. Unglücklicherweise ist iSCSI noch nicht auf hohem Sicherheitsniveau, auch wenn neue Standards auf dem Weg sind. Während IPsec durch den im IP-Protokoll verwendeten Sicherheitsstandard beispielsweise DoS-Attacken abwehren kann, muss diese Funktion in iSCSI erst noch implementiert werden. Der Aufbau von Verschlüsselungsmechanismen und Zugangskontrollen jeder Art, die Speichernetze mit ihren ruhenden und ständig bewegten Daten vor Zugriffen schützen, hat gerade erst begonnen. Neben der Gefahr von außen lauert selbige insbesondere von innen. Gemeint sind Mitarbeiter, die versehentlich  164

Pressemitteilung Symantec, www.symantec.com.

198

8 Schlüsselfaktor IT-Sicherheit

oder absichtlich Informationen einsehen, gebrauchen oder gar verändern, die eigentlich nicht für sie bestimmt sind. Der Wunsch nach schnellem und einfachem Zugang zu allen relevanten Informationen, im Idealfall von jedem Arbeitsplatz weltweit und mobil, unterstreicht die Bedeutung der Information für den Unternehmenserfolg. Auskunft, die von jedem Ort und jederzeit zugänglich ist, gibt erst die Freiheit, erfolgreich Projekte zu managen und Aufgaben an jedem Ort und in jeder Zeitzone effizient abzuwickeln. Die Konsequenz dieser Freiheit ist, dass auch Konkurrenten, Regierungen, Industrie- und Wirtschaftspione und sogar verstimmte Angestellte sich durch bekannte und unbekannte Löcher einen Zugang zu den privilegierten Daten verschaffen können. Außer die Information zu kopieren, können sie sich legitimen Zugang zu den meist schlecht gesicherten Aufbewahrungsorten verschaffen und Informationen verändern oder wertvolle Informationen zerstören. In der vernetzten Speicherwelt sind die Brennpunkte die Zugangspunkte. Wird das Speichernetz direkt an öffentlichen Netzen angeschlossen, ist meist auch eine Hintertür (Back-Tür) geschaffen worden. Die Sicherung bezüglich des Zugangs zu vertraulichen Informationen ist ein kontinuierlicher Akt. Die Orientierung an „Best Practices“ setzt einen unternehmensweiten IT-Sicherheitsplan voraus, der erst in einem einheitlichen und durchgängigen unternehmensweiten IT-Sicherheitsmanagementplan seinen Abschluss findet. Aktuell ist es noch wesentlich einfacher, die an einem festen Ort gespeicherten Daten auszuspionieren als solche, die nur durch das Netz fließen. So bieten zentrale Datenspeicherungen eine beängstigend große Angriffsfläche für die mehr als 25 unterschiedlichen Angriffstechniken allein aus dem Internet. Sichere Datenspeicherung ist aber entscheidend, um das geistige Eigentum und die Betriebsgeheimnisse zu schützen und sich gemäß den einschlägigen Vorschriften zu verhalten (wie z. B. Sarbanes-Oxley, HIPAA, Gramm-Leach-Bliley und SEC 17a4).

8.3 Klassische Sicherheitskonzepte der zentralen Datenspeicherung Gegenwärtige IT-Sicherheitskonzepte in den zentralen Datenspeicherinfrastrukturen sind darauf fokussiert, die externe Grenze zu schützen, d. h. den Standort des Datenspeichers und den notwendigen Verkehr bei Zugriff auf den zentralen Datenspeicher nur über sichere Netzwerke zu erlauben. Nur wo dies aus wirtschaftlichen Gründen nicht möglich ist, werden virtuelle Privatnetze (VPNs) und in Routern spezifische Zugriffssicherungslisten, die sogenannten Access Control List (ACL) eingesetzt. Die Instrumente im Bereich IT-Sicherheit sind: x x x x x

Firewalls, Virtuelle Private Network (VPNs), Access Control List (ACLs), Fibre Channel (FC) Verkabelung und Kontinuierliche Datensicherung.

8.3 Klassische Sicherheitskonzepte der zentralen Datenspeicherung

199

8.3.1 Firewall Eine Firewall ist entweder eine spezifische Hard- oder Software oder eine Kombination von beiden, die den Zugriff von außen auf das Rechnernetz einschränkt oder gar ganz verhindert. In einer Firewall werden spezifische Sicherheitskonzepte umgesetzt. Hardwarekomponenten einer Firewall sind Rechner mit Netzwerkschnittstellen wie Router oder Hosts. Softwarekomponenten einer Firewall sind spezifische Paketfilter, Stateful Inspections, Content Filter oder Proxyserver. Der Einsatzzweck einer Firewall im Rahmen von ILM besteht darin, den Datenverkehr zwischen einem zu schützenden lokalen Speichernetzwerk (NAS oder SAN) und dem Internet zu kontrollieren. Zusätzlich werden immer häufiger „Intrusion Detection Systeme (IDS)“ und „Intrusion Prevention Systeme (IPS)“ in eine Firewall integriert. Da IDS einen Einbruchversuch in ein System durch die Analyse von Kommunikationsmustern (zum Beispiel Portscans) aufdeckt, ist es aber wohl nicht wirklich als Firewalltechnologie anzusehen. IPS ist eine aktive und damit eine effektive Firewalltechnologie, die nach dem Erkennen eines Einbruchversuches geeignete Gegenmaßnahmen einleitet, wie z. B. das zeitlich begrenzte Sperren der vermutlich attackierenden IP-Adresse.

8.3.2 Virtual Private Network Ein Virtual Private Network (VPN) ist ein Netzwerk, das zum Transport privater Daten ein öffentlich zugängliches Netz, wie zum Beispiel das Internet, nutzt. Man unterscheidet grundsätzlich bei VPNs zwischen zwei Formen: x Site-to-Site: Sollen zwei lokale Netze verbunden werden, wird auf beiden Seiten ein VPN-Gateway verwendet. Diese bauen dann untereinander eine VPN-Verbindung auf. Andere Rechner in einem lokalen Netz verwenden nun den Gateway auf ihrer Seite, um Daten in das andere Netz zu senden. So lassen sich zum Beispiel zwei weit entfernte Standorte einer Firma verbinden (Site-to-Site-VPN). x Site-to-End: VPNs werden oft verwendet, um Mitarbeitern außerhalb einer Organisation oder eines Unternehmens Zugriff auf das interne Netz zu geben. Dabei baut der Computer des Mitarbeiters eine VPN-Verbindung zu dem ihm bekannten VPN-Gateway des Unternehmens auf. Über diese Verbindung ist es dem Mitarbeiter nun möglich, so zu arbeiten, als ob er im lokalen Netz der Firma wäre (Remote-Access-VPN). Dieses Verfahren wird auch verwendet, um WLANs und andere Funkstrecken zu sichern (End-to-Site-VPN). Der Begriff „Private“ in VPN impliziert jedoch nicht, wie vielfach angenommen, dass es sich zwingend um eine verschlüsselte Übertragung handelt. Private bedeutet lediglich, eine Verbindung der Netze wird über einen Tunnel zwischen dem VPN-Client und VPN-Server (Concentrator) hergestellt, der oft eine feste Bandbreite als Übertragungskapazität hat. Meist wird der Tunnel dabei gesichert, aber auch ein ungesicherter Klartexttunnel ist ein VPN. IP-VPNs nutzen das Internet zum Transport von IP-Protokoll-basierten Paketen unabhängig

200

8 Schlüsselfaktor IT-Sicherheit

vom Übertragungsnetz, was im Gegensatz zum direkten Remote-Zugriff auf ein internes Netz häufig wesentlich flexibler und kostengünstiger ist. Meist ist ein Nebenprodukt der Verschlüsselung die Datenkomprimierung, so dass sich der Mehraufwand für Verschlüsselung und Datenkomprimierung in geringeren Bandbreiten bei der Datenübertragung auszahlt. VPNs in Speichernetzwerken sind immer dann nützlich: x wenn feste, garantierte Bandbreiten zwingend erforderlich sind, x wenn öffentliche Netze wie das Internet genutzt und die Daten gekapselt oder verschlüsselt werden müssen und x wenn die vorhandene Bandbreite für die geforderte Datenübertragungsrate nicht ausreicht.

8.3.3 Access Control List Für die Beurteilung der Sicherheit von Computersystemen werden die Sicherheitssysteme zur Verwaltung von Zugriffsrechten in zwei Klassen eingeteilt: x Discretionary Access Control: Zugriff wird aufgrund der Identität des Akteurs (Benutzers) und Objektes gewährt oder verweigert. In diese Klasse fällt zum Beispiel der Zugriffsschutz für Dateien in den gängigen Dateisystemen. x Mandatory Access Control bzw. multiliterale Sicherheitsmodelle: Hier wird der Zugriff aufgrund allgemeiner Regeln und Eigenschaften von Objekten und Subjekten gewährt oder verweigert. Dies ist ein wichtiger Bestandteil von Hochsicherheitssystemen und geht oft mit der Forderung einher, dass die Zugriffskontrolle durch einen Referenzmonitor implementiert wird. Modell und Verwaltung der Zugriffsrechte ist ein wichtiger Bestandteil sicherer Computersysteme und daher Kriterium der Zertifizierung gemäß den gängigen Sicherheitsstandards wie TCSEC und ITSEC. Eine Möglichkeit, die Zugriffsrechte sehr flexibel zu gestalten, sind somit die Zugriffskontrolllisten: Für jedes zu schützende Objekt gibt es eine Liste, die für jeden Benutzer (Benutzerrolle) oder jede Gruppe angibt, welche Zugriffe erlaubt sind und welche nicht. Die Access Control List (ACL) wird von Betriebssystemen und Anwendungen auf dem Server verwendet, um zu kontrollieren, welcher Benutzer zu welchen Diensten (Dateien, Netzwerkdiensten) Zugang hat. ACLs sind meist feiner einstellbar als reguläre Zugriffsrechte. So ist es mit vielen ACL-Systemen möglich, einem Prozess, beispielsweise dem FTP-Server-Prozess, exakt die Rechte zu geben, die er zur Erledigung seiner Aufgaben braucht, aber nicht mehr. So darf er etwa seine Konfigurationsdatei lesen, Programmbibliotheken laden etc. Der Prozess darf aber keine Shell starten oder bestimmte Systemaufrufe ausführen, wie es unter Unix oft der Fall ist. In der Unixwelt versteht man unter Access Control List eine Erweiterung der „normalen“ Zugriffssteuerung auf Ebene des Benutzer-Gruppe-Welt-Modells. Bei Access Control Lists lassen sich Zugriffsrechte spezifisch für einzelne Benutzer zuteilen oder verbieten. Als erstes Unix unterstützte HP-UX dieses Modell

8.3 Klassische Sicherheitskonzepte der zentralen Datenspeicherung

201

der erweiterten Zugriffssteuerung. Mittlerweile bieten auch Linux, FreeBSD (TrustedBSD) und Solaris (TrustedSolaris) native Unterstützung für ACLs. Unter Linux unterstützen dabei die Dateisysteme ext2, ext3, JFS, XFS und ReiserFS ACLs vollständig. Mit der KDE-Version 3.5 steht auch der Dateimanager Konqueror mit nativer ACL-Unterstützung zur Verfügung. Für den GNOMEDesktop beherrscht der Dateimanager Nautilus seit Version 2.16 native ACLs. ACLs werden in Linux statisch vererbt, d. h., die Berechtigungen pflanzen sich in neu angelegte Unterverzeichnisse und Dateien je nach Bedarf fort. Wird die ACL eines übergeordneten Verzeichnisses geändert, so hat dies keinen Einfluss auf die darunterliegende Struktur. Unter Microsoft Windows (XP, 2003 Server) ist jedem Betriebssystemobjekt (Dateien, Prozesse etc.) ein Security Descriptor zugeordnet, der eine ACL enthalten kann. Ist keine ACL vorhanden, so erhält jeder Benutzer einen Vollzugriff auf das Objekt. Ist die ACL vorhanden, aber leer, so erhält kein Benutzer einen Zugriff. Eine ACL besteht aus einem Header und maximal 1.820 Access Control Entries (ACE). Ein ACE enthält jeweils die Information, ob einem Benutzer oder einer Benutzergruppe eine bestimmte Zugriffsart erlaubt (allow) oder verweigert (deny) werden soll. Der Windows-Explorer schreibt die Einträge, die Zugriff verweigern, an den Anfang der ACL. Fordert nun ein Benutzer Zugriff auf ein Objekt an, so geht der Windows Object Manager die Liste von Anfang an durch. Sobald Einträge für alle angeforderten Rechte gefunden wurden, erlaubt oder verweigert der Object Manager entsprechend den Zugriff. Trifft der Object Manager beim Durchgehen der Liste auf einen Eintrag, der den Zugriff verweigert, wird die Suche abgebrochen und der Zugriff auf das Objekt verweigert. Bei Windows NT werden ACLs statisch vererbt, ab Windows 2000 geschieht dies dynamisch. Wird die ACL eines übergeordneten Verzeichnisses geändert, kann dies nach Abfrage Auswirkungen auf die darunterliegende Verzeichnisstruktur haben.

8.3.4 FC-Verkabelung Einer der Nutzen einer FC-basierten SAN- oder NAS-Verkabelung ist, dass jeder I/O über Glasfaser erfolgt. Dies vermindert dramatisch die Wahrscheinlichkeiten des unberechtigten „Schnüffelns“.

8.3.5 Kontinuierliche Datensicherung Durch den Einsatz von SAN ist es möglich, die Daten kontinuierlich in Echtzeit auf mindestens zwei verschiedene Speichersysteme in unterschiedlichen Brandschutz-Abschnitten oder Standorten synchron oder asynchron zu spiegeln. Die Informationen werden durch entsprechende Softwarelösungen automatisch und nicht mehr zu fest vorgegebenen Zeiten vollständig oder teilweise gesichert. Ideal ist die synchrone Sicherung nach jeder Änderung in einer Datei in Form von einzelnen Ständen, d. h. einzelnen Snapshots. Das Risiko eines Datenverlustes durch die kontinuierliche Datensicherung, die Continous-Data-Protection (CDP), in

202

8 Schlüsselfaktor IT-Sicherheit

Echtzeit wird zusätzlich deutlich verringert. Im Fall eines Angriffs durch Schadprogramme auf die IT-Systeme – wie einen Virus oder einen Trojaner – kann es trotz optimaler Sicherheitsvorkehrungen durchaus eine gewisse Zeit dauern, bis die Infizierung überhaupt registriert wird. Dank der kontinuierlichen Sicherung der Daten sowie deren Rücksicherung durch regelmäßige Snapshots ist es möglich, die zuletzt gespeicherte, „saubere“ Version der angegriffenen Datei wiederherzustellen. Die vorgestellten Methoden konzentrieren sich bisher fast ausschließlich auf die Grenze der vertrauenswürdigen Seiten des Speichernetzes. Hier soll der Zugriff aus anderen Netzwerken auf den Server, auf dem die Applikation gehostet ist, verhindert werden. Wann auch immer eine neue Dienstleistung oder ein neuer User benötigt wird, so müssen diese bei der Sicherheitsbarriere freigeschaltet werden. Nur wenn sie richtig konfiguriert wurden, genehmigt die Firewall und die definierten Zugriffsrechte jenen den Zugang, die ins geschützte Netz gelangen dürfen. Das Regelwerk einer Firewall ist jedoch sehr schnell sehr anspruchsvoll und bedarf einer kontinuierlichen Pflege, wie dies nur in wenigen Unternehmen der Fall ist. Meist nur zu Beginn setzt der Firewalladministrator noch konsequent den Grundsatz um, dass alles, was nicht ausdrücklich erlaubt, verboten ist. Jedoch wird meist schon nach kurzer Zeit von den Firewalladministratoren auf Zuruf freigeschaltet und danach oftmals das Schließen beim Entfallen des Grundes vergessen. Bei der Isolierung des Speichers muss deshalb der Grundsatz lauten, wenn eine Verbindung der Speicherumgebung mit dem Internet ermöglicht ist, dann dürfen Daten nicht im Klartext verteilt werden. Daten sollten hier konsequent nur verschlüsselt aufbewahrt werden.

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung Zentrale Datenspeicherinfrastrukturen, die nur über ein sicheres Netzwerk einen Zugriff erlauben, decken meist nicht die Anforderungen an einen modernen Informationsservice ab. Größere Speicherzugänglichkeit heißt, dass mehr Zugang auf die Daten existiert. Dies schließt LAN, Campus, MAN (Metropolitan Area Network – ein Datennetz mit mittlerer geografischer Ausdehnung; maximal mehrere 100 Kilometer), WAN und drahtlosen Zugang für NAS- und SANNetze ein. Mehr Zugangspunkte heißen auch, dass mehr Aufmerksamkeit in Form erhöhter IT-Sicherheitsanforderungen gezahlt werden muss.

8.4.1 Ergänzende IT-Sicherheitsmaßnahmen In Ergänzung zu den IT-Sicherheitsinstrumenten einer zentralen Datenhaltung sind, bedingt durch die veränderte Bedrohungslage, weitere Maßnahmen notwendig. Ein wichtiges Instrument zum Aufbau einer sicheren Umgebung ist

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

203

neben der bereits vorgestellten Access Control List (ACL) die Edge Switch Access Control List. Die Edge Switch-ACL findet Anwendung im Rahmen der Multiprotocol Label Switching (MPLS-) Technologie, die von Cisco Systems unter dem Namen „Tag Switching“ entwickelt wurde. Später wurde es durch die IETF als offener Standard definiert und in „Label Switching“ umbenannt. Der Zusatz „Multiprotocol“ beschreibt, dass die MPLS-Technologie unterhalb des IP-Layers angesiedelt ist und beliebige Protokolle darauf aufsetzen werden können. Insbesondere die weitreichenden Fähigkeiten Traffic Engineering und Quality-of-Service (QoS) gehören zu den großen Vorteilen von MPLS. Als Einsatzgebiete eignen sich hierbei vor allem die großen Carrier-Backbone-Netze. Der eingehende Router eines MPLS-Tunnel wird Ingress Router bezeichnet, der ausgehende Router hingegen Engress Router. Beide Router werden als Edge Label Switch Router (ELSR) bezeichnet, da sie die Grenze des MPLS-Netzwerkes darstellen. Router im Inneren des MPLS-Netzwerkes werden als Label Switch Router (LSR) bezeichnet. Nach Eintreffen eines Paketes am Ingress Router wird das entsprechende Paket mit einem (oder mehreren) Label(s) versehen und anschließend an den nächsten Router des MPLS-Tunnels weitergeleitet. Wird ein mit einem Label versehenes Paket von einem LSR empfangen, wertet dieser das oberste Label aus. Nachdem der Austausch des Labels vorgenommen wurde, kann das Paket an den nächsten Router des Tunnels weitergeleitet werden. Zudem kann ein weiteres Label hinzugefügt werden, was auch „Encapsulation“ genannt wird und über eine Push-Operation realisiert wird. Genauso kann auch ein Label durch eine Pop-Operation entfernt werden und einen darunterliegenden Label zum Vorschein bringen, was „Decapsulation“ genannt wird. Diese Vorgehensweise erlaubt ein hierarchisches Routing von MPLS-Paketen. Während der Operationen wird der Inhalt des Paketes außerhalb des MPLS-LabelStacks nicht beachtet.

8.4.2 Port Based Network Access Control Seit 2001 gibt es den Standard 802.1x, der Port Based Network Access Control bei Netzwerken nachrüstet. Diese können drahtlos (WLANs) oder drahtgebunden sein. Die Authentifizierung der Benutzer erfolgt dabei über das Extensible Authentication Protocol (EAP). Zwischen Client und Basisstation werden über EAP die Authentifizierungsdaten ausgetauscht. Die Überprüfung der Daten erfolgt aber nicht durch die Basisstation, sondern durch einen Radius-Server im Hintergrund.

8.4.3 Mandatory Access Control Zur Erhöhung des IT-Sicherheitslevels insbesondere bei Speichernetzwerken wurde das Konzept der Mandatory Access Control (MAC) entwickelt. MAC ist ein Konzept für die Kontrolle und Durchsetzung von Zugriffsrechten auf ITSysteme, bei der die Entscheidung über Zugriffsberechtigungen nicht aufgrund der Identität des Akteurs (Benutzers, Prozesses) und des Objektes (Datei, Gerät)

204

8 Schlüsselfaktor IT-Sicherheit

gefällt wird, sondern aufgrund allgemeiner Regeln und Eigenschaften des Akteurs und Objektes. Auch erhalten häufig Programme eigene Rechte, die die Rechte des ausführenden Benutzers weiter einschränken. Voraussetzung ist, dass Akteure niemals direkt, sondern nur durch einen Referenzmonitor auf Objekte zugreifen können. Das MAC-Modell ist vor allem dazu geeignet, die Vertraulichkeit und Konsistenz von Daten zu sichern. Es dient also dazu, den Informationsfluss zu kontrollieren, und so das „Abfließen“ geschützter Information zu verhindern, sowie zu gewährleisten, dass sich die Daten immer in einem konsistenten Zustand befinden.

8.4.4 Role Based Access Control Role Based Access Control (RBAC) ist in Mehrbenutzersystemen oder Rechnernetzen ein Verfahren zur Zugangskontrolle auf Dateien oder Dienste. Bei der Role Based Access Control werden die Benutzer des Computers oder Netzwerks in Gruppen eingeteilt. Benutzer können dabei mehreren Gruppen angehören. Je nach Gruppenzugehörigkeit erteilt oder sperrt das System dann das Zugriffsrecht auf Ressourcen. Häufig werden vor allem Lesen, Schreiben und Ausführen von Dateien mittels RBAC kontrolliert, das Verfahren ist jedoch nicht darauf beschränkt. Eine Gruppe wird als „Role“ (Rolle) bezeichnet. Der Grund dafür ist, dass sich die Unterteilung der Benutzer danach richtet, in welcher Rolle, also in Ausübung welcher Aufgaben, sie auf den Computer zugreifen. Das englische Wort „Role“ wird im IT-bezogenen deutschen Sprachgebrauch unter anderem für Webmaster, Postmaster, Newsmaster, Netzwerkadministratoren, Systemadministratoren und ähnliche Funktionen verwendet und soll verdeutlichen, dass es sich nicht zwangsläufig um verschiedene Personen handelt, sondern dass zum Beispiel ein und dieselbe Person einmal in der Rolle des Webmasters die Webseiten aktualisiert, dann in der Rolle des Postmasters die Beschwerden über sein offenes MailRelay liest und als Nächstes in der Rolle des Systemadministrators neue Software installiert. Wegen der zweistufigen Gliederung in Benutzer einerseits und „Rollen“ bzw. Gruppen andererseits ist es möglich, Zugriffsrechte nicht nur individuell für einzelne Benutzer, sondern auch für ganze Gruppen freizugeben oder zu sperren.

8.4.5 Management der Speicherinfrastruktur Ein weiterer wichtiger Punkt in einem IT-Sicherheitskonzept betrifft das Management der Speicherinfrastruktur. Leider ist ein ständiger Zugriff auf die heutigen Speichersysteme notwendig, sei es im Rahmen vorbeugender Wartung, sei es im Rahmen von Microcode-Changes, sei es bei der Einrichtung und/oder Erweiterung von Speicher. Die Managementschnittstelle stellt sich allein aufgrund der Anzahl von möglichen Zutrittspunkten, einschließlich der illegalen Konten, als ein hohes IT-Sicherheitsrisiko dar. Aufgrund ihrer Fähigkeit, die Verbindung mit der Umgebung zu unterbrechen, können z. B. Kopier-

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

205

daten zu einem illegalen Empfänger transferiert und danach die Produktionsdaten durch eine einzige Operation als Ganzes gelöscht werden. Das „OnlineSpeichermanagement“ hat damit eine hohe Bewertung der Kritikalität hinsichtlich der IT-Sicherheitssicht. Die Managementzugangspunkte und die Personen, die sie benutzen dürfen, müssen deshalb besonders geschützt werden. In der Tat ist es insbesondere die Menge der Managementschnittstellen, die die Verwundbarkeit erhöht. Erst sie ermöglichen einen absichtlichen oder unabsichtlichen Zugang und eröffnen damit die Möglichkeit zur Änderung von Daten von innerhalb (vertrauenswürdig) oder außerhalb (nicht vertrauenswürdig). Die hier gemachten Änderungen können den Zugang zu Auskunft verhindern (eine Form von DoS oder die Ablehnung von Dienstleistungen), den Zugang eines Eindringlings verbergen oder sich Zugang auf Basis eines legalen Profils verschaffen, Daten verfälschen oder total verändern und abschließend die Anwesenheit des Besuchers durch Ausradierung in den Revisionsbaumstämmen löschen.

8.4.6 Beispiel: IT-Sicherheitsmanagementplanung im Bereich Speicheradministration Generell fehlen spezifische IT-Sicherheitsvorgaben insbesondere beim Thema Speichermanagement. Das Bestreben diese potenzielle IT-Sicherheitslücke zu schließen, hat dazu geführt, dass im Rahmen des beschriebenen Migrationsprojektes (Kap. 12 und ausführlich in Band „Information Lifecycle Management – Prozessimplementierung“) ein eignes Teilprojekt gestartet wurde, das die Aufgabe hatte, insbesondere das IT-Sicherheitsmanagement im Bereich Speicheradministration zu verbessern. Die Durchführung erfolgt gemäß der Beschreibung im IT-Sicherheitsplan (die Erklärung der verwendeten Abkürzungen finden Sie am Ende des Kap. 8.4.6). Die Aufzählung der Maßnahmen soll den notwendigen Arbeitsaufwand für die Sicherstellung des Speichermanagements verdeutlichen. Der Umfang an Maßnahmen zeigt aber auch klar, dass ein auf BSI-Vorgaben basiertes ITSicherheitskonzept sehr aufwendig in der Umsetzung und der kontinuierlichen Betreuung ist.

8.4.6.1 Maßnahmenkatalog Infrastruktur (M 1) Maßnahme M 1.28; G; R M 1.29; U; G; T M 1.31; G M 1.46; M

Lokale unterbrechungsfreie Stromversorgung Geeignete Aufstellung eines IT-Systems Fernanzeige von Störungen; nur bei Speicher Einsatz von Diebstahl-Sicherungen

206

8 Schlüsselfaktor IT-Sicherheit

8.4.6.2 Maßnahmenkatalog Organisation (M 2) Maßnahme M 2.1; O M 2.2; O; M M 2.3; M; U; G M 2.4; O; U; G M 2.5; O M 2.6; O M 2.7; O M 2.8; O M 2.9; V; T; U; W M 2.10; V; M; U; G; W M 2.11; M M 2.12; M M 2.13; O; U; G M 2.14; O M 2.22; U; G; B M 2.25; U; G; T; I; B M 2.26; U; G M 2.30; M; U; G M 2.31; U; G; B M 2.32; U; G M 2.34; U; G; B M 2.35; V; K; U; G; W M 2.38; G M 2.39; O; K M 2.41; D M 2.46; K M 2.62; M M 2.64; M M 2.82; W M 2.83; W M 2.85; W M 2.86; W M 2.87; W M 2.88; W M 2.89; W

Festlegung von Verantwortlichkeiten und Regelungen für den IT-Einsatz Betriebsmittelverwaltung Datenträgerverwaltung Regelungen für Wartungs- und Reparaturarbeiten Aufgabenverteilung und Funktionstrennung Vergabe von Zutrittsberechtigungen Vergabe von Zugangsberechtigungen Vergabe von Zugriffsrechten; im Rahmen der Abnahme Nutzungsverbot nicht freigegebene Software Überprüfung des Software-Bestandes Regelung des Passwortgebrauchs Betreuung und Beratung von IT-Benutzern Ordnungsgemäße Entsorgung von schützenswerten Betriebsmitteln Schlüsselverwaltung Hinterlegen des Passwortes Dokumentation der Systemkonfiguration Ernennung eines Administrators und eines Vertreters Regelung für die Einrichtung von Benutzern / Benutzergruppen Dokumentation der zugelassenen Benutzer und Rechteprofile Einrichtung einer eingeschränkten Benutzerumgebung Dokumentation der Veränderungen an einem bestehenden System Informationsbeschaffung über Sicherheitslücken des Systems Aufteilung der Administrationstätigkeiten Reaktion auf Verletzungen der Sicherheitspolitik Verpflichtung der Mitarbeiter zur Datensicherung Geeignetes Schlüsselmanagement Software-Abnahme- und Freigabe-Verfahren Kontrolle der Protokolldateien ; Voraussetzung in ECC gegeben; aktuell keine Umsetzung Entwicklung eines Testplans für Standardsoftware Testen von Standardsoftware Freigabe von Standardsoftware Sicherstellen der Integrität von Standardsoftware Installation und Konfiguration von Standardsoftware Lizenzverwaltung und Versionskontrolle von Standardsoftware Deinstallation von Standardsoftware

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

207

Maßnahme M 2.90; W M 2.110; M M 2.111; M; B M 2.125; B M 2.126; B M 2.127; B M 2.128; B M 2.129; B M 2.130; B M 2.131; B M 2.132; B M 2.133; B M 2.134; B M 2.135; B M 2.137; D M 2.138; M; G M 2.143; T M 2.144; T M 2.154; V M 2.155; V M 2.156; V M 2.157; V M 2.158; V M 2.159; V M 2.160; V M 2.167; M M 2.177; O M 2.182; M M 2.204; M; G M 2.215; M M 2.216; M M 2.220; M M 2.221; M M 2.222; M

Überprüfung der Lieferung Datenschutzaspekte bei der Protokollierung Bereithalten von Handbüchern Installation und Konfiguration einer Datenbank Erstellung eines Datenbanksicherheitskonzeptes; xx: macht … automatisch Interferenzprävention; macht … automatisch Zugangskontrolle einer Datenbank Zugriffskontrolle einer Datenbank; hat keine userbezogene Accounts Gewährleistung der Datenbankintegrität; macht … automatisch Aufteilung von Administrationstätigkeiten bei Datenbanksystemen Regelung für die Einrichtung von Datenbankbenutzern/benutzergruppen Kontrolle der Protokolldateien eines Datenbanksystems Richtlinien für Datenbank-Anfragen Gesicherte Datenübernahme in eine Datenbank Beschaffung eines geeigneten Datensicherungssystems Strukturierte Datenhaltung Entwicklung eines Netzmanagementkonzeptes Geeignete Auswahl eines Netzmanagement-Protokolls Erstellung eines Computer-Virenschutzkonzepts Identifikation potentiell von Computer-Viren betroffener ITSysteme Auswahl einer geeigneten Computer-Virenschutz-Strategie Auswahl eines geeigneten Computer-Viren-Suchprogramms Meldung von Computer-Virusinfektionen Aktualisierung der eingesetzten Computer-VirenSuchprogramme Regelungen zum Computer-Virenschutz Sicheres Löschen von Datenträgern Sicherheit bei Umzügen Regelmäßige Kontrollen der IT-Sicherheitsmaßnahmen Verhinderung ungesicherter Netzzugänge Fehlerbehandlung Genehmigungsverfahren für IT-Komponenten Richtlinien für die Zugriffs- bzw. Zugangskontrolle Änderungsmanagement Regelmäßige Kontrollen der technischen ITSicherheitsmaßnahmen

208

8 Schlüsselfaktor IT-Sicherheit

Maßnahme M 2.225; O M 2.226; M M 2.227; I M 2.228; I M 2.229; I M 2.230; I M 2.231; I M 2.232; I M 2.233; I

Zuweisung der Verantwortung für Informationen, Anwendungen und IT-Komponenten Regelungen für den Einsatz von Fremdpersonal Planung des Windows 2000 Einsatzes Festlegen einer Windows 2000 Sicherheitsrichtlinie Planung des Active Directory Planung der Active Directory-Administration Planung der Gruppenrichtlinien unter Windows 2000 Planung der Windows 2000 CA-Struktur Planung der Migration von Windows NT auf Windows 2000

8.4.6.3 Maßnahmenkatalog Personal (M 3) Maßnahme M 3.1; P M 3.2; P

Geregelte Einarbeitung/Einweisung neuer Mitarbeiter Verpflichtung der Mitarbeiter auf Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen M 3.3; P Vertretungsregelungen M 3.4; P; V; K; U; G; T; W; B Schulung vor Programmnutzung M 3.5; P; V; K; U; G; T; B Schulung zu IT-Sicherheitsmaßnahmen M 3.6; P Geregelte Verfahrensweise beim Ausscheiden von Mitarbeitern M 3.7; P Anlaufstelle bei persönlichen Problemen M 3.10; U; G; T; B Auswahl eines vertrauenswürdigen Administrators und Vertreters M 3.11, U; G; T; B Schulung des Wartungs- und Administrationspersonals M 3.18; B Verpflichtung der Benutzer zum Abmelden nach Aufgabenerfüllung M 3.26; M Einweisung des Personals in den sicheren Umgang mit IT M 3.27; I Schulung zur Active Directory-Verwaltung

8.4.6.4 Maßnahmenkatalog Hard- und Software (M 4) Maßnahme M 4.1; G; B M 4.2; U; G M 4.3; V; G M 4.7; U; G; B M 4.9; U; R

Passwortschutz für IT-Systeme Bildschirmsperre Regelmäßiger Einsatz eines Viren-Suchprogramms Änderung voreingestellter Passwörter; … hat kein eigenes StandardPasswort Einsatz der Sicherheitsmechanismen von X-Windows; nur nach telefonischer Abstimmung und Anforderung

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

209

Maßnahme M 4.13; U; R M 4.14; U; R M 4.15; U; G M 4.16; U; G M 4.17; U; G M 4.18; U; R M 4.19; U; R M 4.20; U; R M 4.21; U; R M 4.22; U; R M 4.23; U; R M 4.24; G M 4.25; U; R M 4.26; U; R M 4.30; K M 4.33; V M 4.42; M M 4.44; V; G M 4.56; I M 4.65; M; G M 4.67; B M 4.68; M; B M 4.69; B M 4.70; B M 4.71; B M 4.73; B M 4.78; W M 4.84; V M 4.91; T M 4.92; T M 4.93; R M 4.105; U; R M 4.106; U; R M 4.107; R M 4.136; I

Sorgfältige Vergabe von IDs Obligatorischer Passwortschutz unter Unix Gesichertes Login Zugangsbeschränkungen für Accounts und / oder Terminals Sperren und Löschen nicht benötigter Accounts und Terminals Administrative und technische Absicherung des Zugangs zum Monitor- und Single-User-Modus Restriktive Attributvergabe bei Unix-Systemdateien und UnixVerzeichnissen Restriktive Attributvergabe bei Unix-Benutzerdateien und UnixVerzeichnissen Verhinderung des unautorisierten Erlangens von Administratorrechten Verhinderung des Vertraulichkeitsverlusts schutzbedürftiger Daten im Unix-System Sicherer Aufruf ausführbarer Dateien Sicherstellung einer konsistenten Systemverwaltung Einsatz der Protokollierung im Unix-System Regelmäßiger Sicherheitscheck des Unix-Systems Nutzung der in Anwendungsprogrammen angebotenen Sicherheitsfunktionen Einsatz eines Viren-Suchprogramms bei Datenträgeraustausch und Datenübertragung Implementierung von Sicherheitsfunktionalitäten in der ITAnwendung Prüfung eingehender Dateien auf Makro-Viren Sicheres Löschen unter Windows-Betriebssystemen Test neuer Hard- und Software Sperren und Löschen nicht benötigter Datenbank-Accounts Sicherstellung einer konsistenten Datenbankverwaltung Regelmäßiger Sicherheitscheck der Datenbank; macht … automatisch Durchführung einer Datenbanküberwachung; macht … automatisch Restriktive Handhabung von Datenbank-Links; macht … automatisch Festlegung von Obergrenzen Sorgfältige Durchführung von Konfigurationsänderungen Nutzung der BIOS-Sicherheitsmechanismen Sichere Installation eines Systemmanagementsystems Sicherer Betrieb eines Systemmanagementsystems Regelmäßige Integritätsprüfung Erste Maßnahmen nach einer Unix-Standardinstallation Aktivieren der Systemprotokollierung Nutzung von Hersteller-Ressourcen Sichere Installation von Windows 2000

210

8 Schlüsselfaktor IT-Sicherheit

Maßnahme M 4.137; I M 4.138; I M 4.139; I M 4.140; I M 4.141; I M 4.142; I M 4.143; I M 4.144; I M 4.145; I M 4.146; I M 4.147; I M 4.148; I M 4.149; I

Sichere Konfiguration von Windows 2000 Konfiguration von Windows 2000 als Domänen-Controller Konfiguration von Windows 2000 als Server Sichere Konfiguration wichtiger Windows 2000 Dienste Sichere Konfiguration des DDNS unter Windows 2000 Sichere Konfiguration des WINS unter Windows 2000 Sichere Konfiguration des DHCP unter Windows 2000 Nutzung der Windows 2000 CA Sichere Konfiguration von RRAS unter Windows 2000 Sicherer Betrieb von Windows 2000 Sichere Nutzung von EFS unter Windows 2000 Überwachung eines Windows 2000 Systems Datei- und Freigabeberechtigungen unter Windows 2000

8.4.6.5 Maßnahmenkatalog Kommunikation (M 5) Maßnahme M 5.6; G M 5.7; G M 5.8; G

Obligatorischer Einsatz eines Netzpasswortes Netzverwaltung Monatlicher Sicherheitscheck des Netzes / regelmäßiger SicherheitsCheck M 5.9; G Protokollierung am Server M 5.10; G Restriktive Rechtevergabe M 5.13; G Geeigneter Einsatz von Elementen zur Netzkopplung M 5.16; R Übersicht über Netzdienste M 5.17; U; R Einsatz der Sicherheitsmechanismen von NFS M 5.18; U; R Einsatz der Sicherheitsmechanismen von NIS M 5.19; U; R Einsatz der Sicherheitsmechanismen von Sendmail M 5.20; U; R Einsatz der Sicherheitsmechanismen von rlogin, rsh und rcp M 5.21; U; R Sicherer Einsatz von Telnet, ftp, tftp und rexec M 5.33; K Absicherung der per Modem durchgeführten Fernwartung M 5.50; K Authentisierung mittels PAP/CHAP M 5.52; K Sicherheitstechnische Anforderungen an den Kommunikationsrechner M 5.58; S; B Installation von ODBC-Treibern; macht … automatisch M 5.59; S Schutz vor DNS-Spoofing M 5.60; S Auswahl einer geeigneten Backbone-Technologie M 5.61; S Geeignete physikalische Segmentierung M 5.62; S Geeignete logische Segmentierung M 5.64; K; S; U; R Secure Shell

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

211

Maßnahme M 5.65; K; S M 5.66; K; S M 5.67; S M 5.68; S; M; T; I M 5.72; U; R M 5.77; M M 5.87; M M 5.88; M

Einsatz von S-HTTP Verwendung von SSL Verwendung eines Zeitstempel-Dienstes Einsatz von Verschlüsselungsverfahren zur Netzkommunikation Deaktivieren nicht benötigter Netzdienste Bildung von Teilnetzen Vereinbarung über die Anbindung an Netze Dritter Vereinbarung über Datenaustausch mit Dritten

8.4.6.6 Maßnahmenkatalog Notfallvorsorge (M 6) Maßnahme M 6.1; N M 6.2; N M 6.3; N M 6.4; N M 6.5; N M 6.6; N M 6.7; N M 6.8; N M 6.9; N M 6.10; N M 6.11; N M 6.12; N M 6.13; N M 6.16; N M 6.17 M 6.20; U; G M 6.21; U; G; W M; 6.22; U; G

Erstellung einer Übersicht über Verfügbarkeitsanforderungen Notfall-Definition, Notfall-Verantwortlicher Erstellung eines Notfall-Handbuches Dokumentation der Kapazitätsanforderungen der IT-Anwendungen Definition des eingeschränkten IT-Betriebs Untersuchung interner und externer Ausweichmöglichkeiten Regelung der Verantwortung im Notfall Alarmierungsplan Notfall-Pläne für ausgewählte Schadensereignisse Notfall-Plan für DFÜ-Ausfall Erstellung eines Wiederanlaufplans Durchführung von Notfallübungen Erstellung eines Datensicherungsplans Abschließen von Versicherungen Alarmierungsplan und Brandschutzübungen Geeignete Aufbewahrung der Backup-Datenträger Sicherungskopie der eingesetzten Software Sporadische Überprüfung auf Wiederherstellbarkeit von Datensicherungen M 6.25; G Regelmäßige Datensicherung der Server-Festplatte M 6.31; U; G; R Verhaltensregeln nach Verlust der Systemintegrität M 6.32; U; G; I; B Regelmäßige Datensicherung M 6.33; D Entwicklung eines Datensicherungskonzepts M 6.37; D Dokumentation der Datensicherung M 6.41; D Übungen zur Datenrekonstruktion M 6.43; I Einsatz redundanter Windows NT/2000 Server M 6.48; B Verhaltensregeln nach Verlust der Datenbankintegrität; xx: einspielen des Backups

212

8 Schlüsselfaktor IT-Sicherheit

Maßnahme M 6.49; B M 6.50; B M 6.51; B M 6.57; T M 6.75; N; M M 6.78; I

Datensicherung einer Datenbank Archivierung von Datenbeständen Wiederherstellung einer Datenbank Erstellen eines Notfallplans für den Ausfall des Managementsystems Redundante Kommunikationsverbindungen Datensicherung unter Windows 2000

8.4.6.7 Katalog der entfallenen Maßnahmen Nachfolgende Maßnahmenliste sind Beispiele für gestrichene Aktivitäten, die sich ergeben, wenn auf Basis des BSI-Maßnahmenkatalogs der einzelnen Bausteine die IT-Sicherheitsmaßnahme erarbeitet werden. Diese Maßnahmen wurden z. B. in den beschriebenen Projekt als nicht relevant für das Speichermanagement eingestuft. Maßnahme M 1.34; M

Geeignete Aufbewahrung tragbarer PCs im stationären Einsatz

M 2.33; U; R M 2.36 M 2.37; O M 2.40; O; T; I; W M 2.65; B M 2.66; W M 2.69; M M 2.79; W M 2.80; W; B M 2.81; W M 2.84; W

Aufteilung der Administrationstätigkeiten unter Unix Geregelte Übergabe und Rücknahme eines tragbaren PC „Der aufgeräumte Arbeitsplatz“ Rechtzeitige Beteiligung des Personal- / Betriebsrates Kontrolle der Wirksamkeit der Benutzer-Trennung am IT-System Beachtung des Beitrags der Zertifizierung für die Beschaffung Einrichtung von Standardarbeitsplätzen Festlegung der Verantwortlichkeiten im Bereich Standardsoftware Erstellung eines Anforderungskatalogs für Standardsoftware Vorauswahl eines geeigneten Standardsoftwareproduktes Entscheidung und Entwicklung der Installationsanweisung für Standardsoftware geeignete Auswahl einer Datenbank-Software Entwicklung eines Kryptokonzepts Bedarfserhebung für den Einsatz kryptographischer Verfahren und Produkte Erhebung der Einflussfaktoren für kryptographische Verfahren und Produkte Auswahl eines geeigneten kryptographischen Verfahrens Auswahl eines geeigneten kryptographischen Produktes Regelung des Einsatzes von Kryptomodulen IT-System-Analyse vor Einführung eines Systemmanagementsystems

M 2.124; B M 2.161; V M 2.162; V M 2.163; V M 2.164; K M 2.165; K M 2.166; K M 2.168; T

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

213

Maßnahme M 2.169; T M 2.170; T M 2.171; T M 2.214; M M 2.217; M M 2.218; M M 2.219; M M 2.223; M M 3.23; K M 4.29; K M 4.34; K; W M 4.40; U; R M 4.41; K M 4.72; K; B M 4.85; K M 4.86; K M 4.87; K M 4.88; K M 4.89; K M 4.90; K M 4.109; M M 4.133; M M 4.134; M M 4.135; M M 5.34; K; U; R M 5.35; U; R M 5.36; K; U; R M 5.37; I M 5.38; R M 5.63; K; S M 5.82; R M 5.83; R M 5.89; I M 5.90; I M 6.14; N M 6.15; N

Entwickeln einer Systemmanagementstrategie Anforderungen an ein Systemmanagementsystem Geeignete Auswahl eines Systemmanagement-Produktes Konzeption des IT-Betriebs Sorgfältige Einstufung und Umgang mit Informationen, Anwendungen und Systemen Regelung der Mitnahme von Datenträgern und IT-Komponenten Kontinuierliche Dokumentation der Informationsverarbeitung Sicherheitsvorgaben für die Nutzung von Standardsoftware Einführung in kryptographische Grundbegriffe Einsatz eines Verschlüsselungsproduktes für tragbare PCs Einsatz von Verschlüsselung, Checksummen oder Digitalen Signaturen Verhinderung der unautorisierten Nutzung des Rechnermikrofons Einsatz eines angemessenen PC-Sicherheitsproduktes Datenbank-Verschlüsselung Geeignetes Schnittstellendesign bei Kryptomodulen Sichere Rollenteilung und Konfiguration bei Kryptomodulen Physikalische Sicherheit von Kryptomodulen Anforderungen an die Betriebssystem-Sicherheit beim Einsatz von Kryptomodulen Abstrahlsicherheit Einsatz von kryptographischen Verfahren auf den verschiedenen Schichten des ISO/OSI-Referenzmodells Software-Reinstallation bei Arbeitsplatzrechnern Geeignete Auswahl von Authentikations-Mechanismen Wahl geeigneter Datenformate Restriktive Vergabe von Zugriffsrechten auf Systemdateien Einsatz von Einmalpasswörtern Einsatz der Sicherheitsmechanismen von UUCP Verschlüsselung unter Unix und Windows NT Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz Sichere Einbindung von DOS-PCs in ein Unix-Netz Einsatz von GnuPG oder PGP Sicherer Einsatz von SAMBA Sichere Anbindung eines externen Netzes mit Linux FreeS/WAN Konfiguration des sicheren Kanals unter Windows 2000 Einsatz von IPsec unter Windows 2000 Ersatzbeschaffungsplan Lieferantenvereinbarungen

214

8 Schlüsselfaktor IT-Sicherheit

Maßnahme M 6.23; N M 6.24; N M 6.36; D M 6.56; K M 6.76; I M 6.77; I

Verhaltensregeln bei Auftreten eines Computer-Virus Erstellen einer PC-Notfalldiskette Festlegung des Minimaldatensicherungskonzeptes Datensicherung bei Einsatz kryptographischer Verfahren Erstellen eines Notfallplans für den Ausfall eines Windows 2000 Netzes Erstellung von Rettungsdisketten für Windows 2000

Abkürzungserklärung: Arbeitspunkt auf Basis des BSI-Maßnahmenkatalogs, dabei gilt: x x x x x x x x x x x x x x x

O = Kap. 3.1; Organisation, P = Kap. 3.2; Personal, N = Kap. 3.3; Notfallvorsorge-Konzept, D = Kap. 3.4; Datensicherungskonzept, V = Kap. 3.6; Computer-Virenschutzkonzept, K = Kap. 3.7; Kryptokonzept, S = Kap. 3.8; Behandlung von Sicherheitsvorfällen, M = Kap. 3.9; Hard- und Software-Management, U = Kap. 5.2; (USy) Unix-System, G = Kap. 6.1; (SN) Servergestützte Netzwerke, R = Kap. 6.2; (USe) Unix Server, T = Kap. 6.3; (NSM) Netz- und Systemmanagement, I = Kap. 6.9; (WS) Windows Server 2000, W = Kap. 9.1; (SW) Standardsoftware, B = Kap. 9.2; (DB) Datenbanken.

Die Nummer im Anschluss an der Kapitelbezeichnung bezeichnet die Einzelmaßnahme gemäß der BSI-Nummerierung.

8.4.7 SAN-Zoning und LUN-Masking Eine zusätzliche Verbesserung der IT-Sicherheit ist durch SAN-Zoning und LUNMasking möglich. SANs werden mit Hilfe von Fibre-Channel-Switches aufgebaut, die als intelligente Schalteinheiten Server und Speicher miteinander verbinden. Angelehnt an die virtuellen LANs (VLANs) im LAN-Switch findet sich im FibreChannel-Switch eine ähnliche Funktionalität, genannt Zoning. Zoning definiert voneinander abgegrenzte Teilnehmergruppen, die aufgrund von physikalischen Portnummern (Hard-Zoning) oder aufgrund der Adressinformationen im Datenfeld (Soft-Zoning) gebildet werden. Im Kern geht es beim SAN-Zoning und LUN-Masking darum, der Applikation nur die Speicherbereiche sichtbar zu machen, die sie für die Durchführung ihrer Aufgaben braucht, und damit durch Segmentierung den allgemeinen Zugriff auf spezifische Speicherbereiche zu unterbinden.

8.4 Klassische IT-Sicherheitskonzepte in einer verteilten Speicherumgebung

215

SAN-Zoning beschreibt die Unterteilung eines Netzes in virtuelle Subnetzwerke, die sich überlappen können. Server einer Zone können normalerweise nicht auf Speichersysteme einer anderen Zone zugreifen – eine wichtige Sicherheitsmaßnahme gegen Attacken. Es gibt zwei Methoden des Zonings in einer Fabric-Umgebung, d. h. einem Speichernetzwerk. Die beiden Methoden sind Port-Zoning und WWN-Zoning. Port-Zoning nutzt Zonen auf Basis physikalischer Ports und ist daher sehr sicher. Dies bedeutet, dass der Zugriff auf die einzelnen Speichersegmente einem fest definierten Port zugeordnet wird. Die Applikation hat nur Zugriff auf dezidierte Ports und kann demzufolge nur auf die definierten Speicherbereiche zugreifen. Beim World Wide Name (WWN-) Zoning wird der Name des Servers im Switch dazu genutzt, den Zugriff auf partikulare WWNs in der Fabric zu erlauben oder zu blockieren. Ein WWN ist eine 64-Bit-Kennung für eine FibreChannel-Komponente, die weltweit eindeutig ist. WWN-Zoning ist aufgrund seiner deutlich höheren Flexibilität sehr verbreitet, obwohl WWN-Zoning einen deutlich geringeren IT-Sicherheitslevel darstellt. Insbesondere eröffnet das WWN-Zoning die Möglichkeit eines Zugriffs in Form eines Bypasses, falls einem Hacker die IEEE-Adresse des Adapters bekannt ist. Es erlaubt ihm einen „Access“ direkt zum Knoten und damit zu den Daten. Das SCSI-Protokoll und dessen Ableger, Fibre Channel Protocol (FCP) und iSCSI, adressieren Teilkomponenten eines Gerätes (Target) mittels der Logical Unit Number (LUN). Es hat sich eingebürgert, auch diese Teilkomponenten als LUN zu bezeichnen. LUNs sind von einem Disksubsystem exportierte physikalische oder virtuelle Festplatten sowie die Bandlaufwerke und der Roboter einer Tape-Library. LUN-Zoning ist die alternative Bezeichnung für LUN-Masking und beschreibt das Zoning im SCSI-Protokoll. Unterstützt wird das LUN-Masking oftmals noch durch die LUN-Security der Disk-Arrays. Eine LUN ist eine logische Platteneinheit in einem intelligenten Disk-Array. Unter LUN-Security fallen die Begriffe LUN-Binding und LUN-Masking. Das LUN-Masking wird verwendet, um das Zoning auf Basis von LUNs durchzuführen. LUN- Masking schränkt die Sichtbarkeit von Festplatten ein und ist primär im Host-Bus-Adapter (HBA) implementiert. Sie sollen damit verhindern, dass unberechtigte Teilnehmer im SAN-Zugriff auf die LUNs erhalten. LUN-Binding erlaubt die Adressierung der LUNs nur über bestimmte Netzeingänge des Plattensystems. LUN-Masking definiert darüber hinaus noch Zugriffstabellen, in denen die World Wide-Name (WWN-) Adressen der zugriffsberechtigten Server hinterlegt sind. Jeder Server sieht somit nur die Festplatten, die ihm zugewiesen sind. LUN-Masking wird als Filter zwischen den vom Disksubsystem exportierten Festplatten und den zugreifenden Servern etabliert. Auch einige Speicher Controller unterstützen LUN-Masking. Es gibt unterschiedliche Methoden des LUN-Maskings, um den Zugriff (schreibend und/oder lesend) auf partikulare LUN’s in einem Array zu blockieren. Einige Methoden benutzen „Agenten“ auf den Servern, um den Zugang zu besonderen LUNs zu sperren. Wenn ein solcher Agent nicht eingesetzt oder aber falsch konfiguiert bzw. missbräuchlicherweise

216

8 Schlüsselfaktor IT-Sicherheit

etabliert wird, dann existiert mit hoher Wahrscheinlichkeit ein ungesicherter LUN-Zugang von mindestens einem Knoten. Die aus IT-Sicherheitssicht besser geeignete Methode ist, Firmware zu verwenden, um den Zugang zu besonderen LUNs durch die Benutzung des WWN zu ermöglichen bzw. bei Nichterfüllung den Zugriff zu verhindern. Das Arrary speichert die Zugangsliste für den HostAccess in NV-RAM und im Memory. LUN-Masking ist insbesondere beim Einsatz von Windows-Server wichtig, da hier ein uneingeschränkter Zugriff zu allen sichtbaren LUNs erfolgen kann. So wichtig und notwendig die beschriebenen allgemeinen IT-Sicherheitsmaßnahmen und insbesondere die spezifischen IT-Sicherheitsmaßnahmen im SAN mit Zoning und Masking für eine funktionierende SAN-Infrastruktur auch sind, sie erhöhen aber erheblich die Komplexität des Speichermanagements. Dies gilt insbesondere für die dynamische Speicherprovisionierung für Storage-onDemand (SoD) im SAN. Liegen z. B. freie Plattenkapazitäten eines Speicherpools in einer anderen Zone, so muss zuerst der FC-Switch umkonfiguriert werden. Weiterhin sind die LUN-Zugriffstabellen anzupassen, sonst kann ein Server die neuen Speicherbereiche nicht nutzen. Sämtliche Verwaltungsfunktionen im SAN dürfen nur von unbedingt vertrauenswürdigen Instanzen durchgeführt werden. Entsprechend hoch ist der Aufwand bei der Sicherung der zahlreichen Zugangspunkte für das Management der Speicher- und Netzkomponenten. Ist zudem der Managementzugang nur unzureichend abgesichert, so hat man potenziellen Angreifern von innen und außen Tür und Tor weit geöffnet.

8.5 Anforderung an die Organisation und die Betriebsführung Die tägliche Praxis im Bereich der Speicher- und SAN-Administration zeigt häufig, dass die Administratoren bedingt durch die Arbeitsüberlastung meist weder das spezifische, umfängliche Know-how noch die notwendige tägliche Routine aufbauen können, um die sensiblen Aktivitäten in der richtigen Reihenfolge und ohne Fehler durchzuführen. Oftmals wird durch den aufgebauten Zeitdruck ohne ausreichende Planung und fundierte Vorbereitung direkt am „lebenden Objekt“ operiert, d. h. den „Echtdaten“ bzw. den Produktionsdaten. Auch ein entsprechender Herstellersupport kann dann den vorprogrammierten Datenverlust meist nicht mehr verhindern. Die Analyse von SNIA bestätigt dieses subjektive Empfinden der beiden Autoren, indem sie zu dem Ergebnis kommt, dass ein funktionierendes IT-Sicherheitskonzept zu mindestens 80 Prozent auf einer durchgängigen Organisation und einer konsequenten Betriebsführung beruht. Die eigentliche Sicherheitstechnologie macht demzufolge nur 20 Prozent des IT-Sicherheitskonzeptes aus.165  165

SNIA-Security, www.snia.org.

8.5 Anforderung an die Organisation und die Betriebsführung

217

Die beschriebenen Einzelmaßnahmen bei den traditionellen Sicherheitskonzepten bei der zentralen und insbesondere bei der dezentralen Datenspeicherung lösen somit nicht die spezifischen IT-Sicherheitsanforderungen im Generellen und von ILM im Besonderen. Ein unternehmensweites ILM erfordert ein IT-Sicherheitskonzept, das aufsetzend auf den sogenannten „General Security Requirements“ die effizienten Einzelmaßnahmen zu einem wirkungsvollen Gesamtschutz verschweißt.

8.5.1 Das IT-Sicherheitsmanagement im Fokus der verschiedenen IT-Sicherheitsstandards 8.5.1.1 BSI-IT-Grundschutz Ziel des IT-Grundschutzes ist es, durch infrastrukturelle, organisatorische, personelle und technische Standard-Sicherheitsmaßnahmen ein Standard-Sicherheitsniveau für IT-Systeme aufzubauen. Hierzu enthält das IT-Grundschutzhandbuch Kataloge mit Standard-Sicherheitsmaßnahmen aus den Bereichen Infrastruktur, Organisation, Personal, Hard- und Software, Kommunikation und Notfallvorsorge. Die Vorgehensweise umfasst die Arbeitsschritte IT-Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, Basis-Sicherheitscheck, Ergänzende Sicherheitsanalyse und Realisierung von IT-Sicherheitsmaßnahmen. Ein funktionierendes IT-Sicherheitsmanagement muss in die existierenden Managementstrukturen einer jeden Institution eingebettet werden.166 Dieser Baustein soll aufzeigen, wie ein funktionierendes IT-Sicherheitsmanagement eingerichtet und im laufenden Betrieb weiterentwickelt werden kann. Der Baustein baut auf dem BSI-Standard 100-1 „Managementsysteme für Informationssicherheit“ und BSI-Standard 100-2 „Vorgehensweise nach IT-Grundschutz“ auf und fasst die wichtigsten Aspekte zum IT-Sicherheitsmanagement hieraus zusammen: x Gefährdungslage, x Organisatorische Mängel, x Maßnahmenempfehlungen. Einer der Grundpfeiler zur Erreichung eines angemessenen Sicherheitsniveaus ist, dass die Leitungsebene hinter den Sicherheitszielen steht und sich ihrer Verantwortung für IT-Sicherheit bewusst ist. Die Leitungsebene muss den IT-Sicherheitsprozess initiieren, steuern und kontrollieren, damit dieser in der Institution auch in allen Bereichen umgesetzt wird (siehe M 2.336 Übernahme der Gesamtverantwortung für IT-Sicherheit durch die Leitungsebene). Nachfolgend wird das Maßnahmenbündel für den Bereich „IT-Sicherheitsmanagement“ in Auszügen vorgestellt:

 166

BSI, www.bsi.de.

218

8 Schlüsselfaktor IT-Sicherheit

Planung und Konzeption – M 2.192 Erstellung einer IT-Sicherheitsleitlinie – M 2.335 Festlegung der IT-Sicherheitsziele und -strategie – M 2.336 Übernahme der Gesamtverantwortung für IT-Sicherheit durch die Leitungsebene Umsetzung – – – –

M 2.193 M 2.195 M 2.197 M 2.337

Aufbau einer geeigneten Organisationsstruktur für IT-Sicherheit Erstellung eines IT-Sicherheitskonzepts Integration der Mitarbeiter in den Sicherheitsprozess Integration der IT-Sicherheit in organisationsweite Abläufe und Prozesse – M 2.338 Erstellung von zielgruppengerechten IT-Sicherheitsrichtlinien – M 2.339 Wirtschaftlicher Einsatz von Ressourcen für IT-Sicherheit Betrieb – – – –

M 2.199 M 2.200 M 2.201 M 2.340

Aufrechterhaltung der IT-Sicherheit Managementreporte und -bewertungen der IT-Sicherheit Dokumentation des IT-Sicherheitsprozesses Beachtung rechtlicher Rahmenbedingungen

8.5.1.2 ISO 17799 Ziel der ISO/IEC 17799 (BS 7799) ist es in erster Linie, eine umfassende Sammlung von Maßnahmen bereitzustellen, die dem Best-Practice-Ansatz in der Informationssicherheit genügen. Die Norm soll gemeinsamer Bezugspunkt zur Identifizierung der verschiedenen Maßnahmen sein. BS 7799 hat die Aufgabe im Teil 1 diese Maßnahmen darzustellen und im Teil 2 eine Basis für die Beurteilung eines Informationssicherheitsmanagementsystems zu bilden, die für ein formales Verfahren zur Zertifizierung herangezogen werden kann. Betrachtet werden Aspekte der Sicherheitspolitik, Organisation der Sicherheit, Einstufung und Kontrolle der Werte, personelle Sicherheit, physische und umgebungsbezogene Sicherheit, Management der Kommunikation und des Betriebs, Zugangskontrollen, Systementwicklung und Wartung, Management des kontinuierlichen Geschäftsbetriebs und die Einhaltung von Verpflichtungen. Die ISO 17799 unterteilt IT-Sicherheitsmanagement zum einen in eine innerbetriebliche und in eine außerbetriebliche Organisation. Das IT-Sicherheitsmanagement sollte aktiv Sicherheit innerhalb der Organisation durch klare Verfahrensanweisungen, direkte Verpflichtungen, ausdrückliche Zuweisung und Ausweis der Sicherheitsverantwortung erzielen. Das Durchführungsmanagement x stellt sicher, dass Sicherheitsziele identifiziert werden, entsprechend den organisatorischen Anforderungen und deren Integration in die dazugehörigen Prozesse; x formuliert, überprüft und genehmigt Sicherheitsrichtlinien;

8.5 Anforderung an die Organisation und die Betriebsführung

219

x überprüft die Wirksamkeit der Durchführung der Sicherheitsrichtlinien; x stellt klare Richtungsanweisungen und sichtbare Managementunterstützung für Sicherheitsinitiativen zur Verfügung; x stellt die benötigten Hilfsmittel für die Sicherheit zur Verfügung; x genehmigt die Zuweisung von bestimmten Rollen und Verantwortung für die Sicherheit in der Organisation; x initiiert die Pläne und Programme, um das Sicherheitsbewusstsein aufzubauen, aufrechtzuerhalten und zu bewahren; x stellt sicher, dass die Durchführung von Sicherheitskontrollen über die Organisation koordiniert wird. Das IT-Sicherheitsmanagement sollte zusätzlich bei Bedarf die Notwendigkeiten der Hinzuziehung von innerbetrieblichen oder außerbetrieblichen Sicherheitsexperten identifizieren. Je nach der Größe der Organisation könnte solche Verantwortung von einem Managementforum oder von einem existierenden Manager verkörpert werden.

8.5.1.3 ISO TR 13335 Die Suite von derzeit vier „Technical Reports“ (ein fünfter zur Sicherheit von Netzen ist geplant) gibt Handreichungen für das IT-Sicherheitsmanagement, ohne bestimmte Lösungen zu erzwingen. Teil 1 „Konzepte und Modelle der IT-Sicherheit“ definiert Grundbegriffe der IT-Sicherheit und grundlegende Aspekte (Bedrohungen, Risiken, Schwachstellen etc.) sowie Prozesse (z. B. Notfallvorsorge, Risikoanalyse, Sensibilisierung). Er richtet sich an verantwortliche Manager und Sicherheitsbeauftragte von Organisationen. Teil 2 „Managen und Planen von IT-Sicherheit“ gibt Hinweise zur Gestaltung des IT-Sicherheitsprozesses, seiner Integration in bestehende Unternehmensprozesse und schlägt eine IT-Sicherheitsorganisation vor. Teil 3 „Techniken für das Management von IT-Sicherheit“ verfeinert die Schritte des IT-Sicherheitsprozesses und gibt Hinweise auf Methoden und Techniken, die dafür genutzt werden können. Teil 4 „Auswahl von Sicherheitsmaßnahmen“ gibt schließlich Hinweise, welche Maßnahmen für welche Bedrohungen in Betracht kommen und wie z. B. ein angemessenes Grundschutzniveau der Organisation bestimmt werden kann.

8.5.1.4 ITSEC Ziel der Evaluationskriterien ITSEC und Common Criteria ist es, ein Prüfverfahren zu definieren, mit dem sicherheitsrelevante Aspekte von Produkten und Systemen der IT auf strukturierte Weise hinsichtlich ihrer Sicherheitseigenschaften solchermaßen untersucht werden können, dass die Ergebnisse dieser Untersuchungen nachvollziehbar und vergleichbar sind. Dazu definieren die Kriterienwerke funktionale und qualitative Anforderungen an die Untersuchungsgegen-

220

8 Schlüsselfaktor IT-Sicherheit

stände, die sich sowohl auf ihre Eigenschaften als auch auf die Verfahren zu ihrer Entwicklung beziehen.

8.5.1.5 FIPS 140-2 Ziel der 1994 von National Institute of Standards and Technology (NIST; USA) herausgegebenen „Security Requirements for Cryptographic Modules“ (FIPS 140-1-Criteria“ als „Federal Information Standard 140“ bzw. zukünftig FIPS 140-2; Federal Information Processing Standards) ist die Validierung von Kryptomodulen. Gemeinsam mit Canadian Security Establishment (CSE) wurde im Juli 1995 das zugehörige „Cryptographic Module Verification Program (CMV)“ eingerichtet, ergänzt um ein „Implementation Guidance Document“ (für die Erläuterung zum Standard und des Validierungsprozesses). Unter der Akkreditierung des „National Voluntary Laboratory Accreditation Program (NVLAP)“ wurden bis 2001 fünf Prüflabore (bis dato ausschl. USA und Kanada) zugelassen.

8.5.1.6 Task Force Zentrale Aufgaben der Task Force „Sicheres Internet“ sind die Auswertung von Informationen sowie die Prüfung von Art und Umfang der Bedrohung in Deutschland und der erforderlichen Gegenmaßnahmen. Bisher wurden Maßnahmenkataloge in Abstimmung mit externen Experten aus Wirtschaft, Wissenschaft und Behörden erarbeitet und im Internet bereitgestellt unter http://www.bsi.bund.de/taskforce. Die jeweiligen Empfehlungen verstehen sich als Leitlinie, den darin angesprochenen Schwachstellen zu begegnen, den Schutz vor Angriffen zu verbessern und vorhandene Risiken zu minimieren. Gleichzeitig dienen sie als Diskussionsgrundlage zur konkreten Realisierung von Maßnahmen in den verschiedensten Bereichen.

8.5.1.7 COBIT Der intensive Einsatz von IT zur Unterstützung und Abwicklung geschäftsrelevanter Abläufe macht die Etablierung eines geeigneten Kontrollumfelds erforderlich. Control Objectives for Information and Related Technology (COBIT) wurde von der Information Systems Audit and Control Association (ISACA, http://www.isaca.org) als Methode entwickelt, um die Vollständigkeit und die Effektivität eines solchen Kontrollumfelds zur Begrenzung der entstehenden Risiken prüfen zu können. Das Management eines Unternehmens ist u. a. für die Erreichung der Geschäftsziele, die Kontrolle der dabei verwendeten Ressourcen hinsichtlich Effektivität und Effizienz, die Einhaltung rechtlicher Rahmenbedingungen sowie die Handhabung der mit der Geschäftstätigkeit und dem Ressourceneinsatz verbundenen Risiken (z. B. Sicherheitsrisiken) verantwortlich. Dies gilt insbesondere für den Einsatz der IT als Ressource zur Realisierung von Geschäftsprozessen.

8.5 Anforderung an die Organisation und die Betriebsführung

221

Zur Unterstützung des Managements und der damit befassten Fachabteilungen wie z. B. Interne Revision bei der Wahrnehmung dieser Verantwortung wurde mit COBIT von der ISACA ein umfassendes Kontrollsystem bzw. Rahmenwerk geschaffen, das alle Aspekte des IT-Einsatzes von der Planung bis zum Betrieb und der Entsorgung berücksichtigt und somit eine ganzheitliche Sicht auf die IT einnimmt. In diese Elemente sind Bestandteile aus insgesamt 41 nationalen und internationalen Standards eingearbeitet und gemeinsam ausgerichtet worden. Anwendungsbereiche sind: x Kontrollziele: COBIT umfasst eine Sammlung international akzeptierter und allgemein einsetzbarer Kontrollziele. Diese repräsentieren drei Sichten auf die IT und stellen die Interessen der jeweiligen Gruppe und deren Ziele dar. Sie umfassen folgende Aspekte: x Managementsicht: Unterstützung bei der Risikobehandlung in der sich ständig ändernden Umgebung und bei der Entscheidung über Investitionen, die zur Gestaltung der Kontrolle nötig sind. x Anwendersicht: Kontrolle und Sicherheit der Informatikdienstleistungen. x Revisionssicht: Einheitliche Grundlage für die Wertung der inneren Kontrollen. Damit unterstützt COBIT die Ziele der IT-Governance im Unternehmen (als Teil der „Corporate bzw. Enterprise Governance“): x Ausrichtung der IT auf die Geschäftstätigkeit: Nutzenmaximierung, x Wirtschaftlicher Einsatz von IT-Ressourcen, x Angemessenes Risikomanagement IT-bezogener Risiken. COBIT stellt sich als Sammlung von Informationen, Werkzeugen und Richtlinien dar, die die Sichtweisen der einzelnen durch IT-Governance angesprochenen Gruppen umfassend und spezifisch abbilden. Die Elemente von COBIT (und die jeweilige Zielgruppe im Unternehmen) sind: x x x x x x

Executive Summary (Senior Executives wie CEO, CIO), Framework (Senior Operational Management), Implementation Toolset (Mittleres Management, Direktoren), Managementrichtlinien (Mittleres Management, Direktoren), Kontrollziele (Mittleres Management), Audit-Richtlinien (Linienmanagement und Revisoren).

Das COBIT-Framework enthält Anforderungen an die Geschäftsprozesse in den Kategorien Qualität, Sicherheit und Ordnungsmäßigkeit sowie den sieben folgenden Zielkriterien: x x x x x x x

Vertraulichkeit, Verfügbarkeit, Integrität, Effektivität, Effizienz, Zuverlässigkeit, Einhaltung rechtlicher Erfordernisse,

222

8 Schlüsselfaktor IT-Sicherheit

Abb. 8.1. Das COBIT-Framework167

Diese werden mit den verwendeten IT-Ressourcen in den Kategorien x x x x x

Daten, Anwendungen, Technologien, Anlagen, Personal

in Zusammenhang gestellt und in die Gesamtsicht des zyklischen Prozesses „Planung & Organisation, Beschaffung & Implementierung, Betrieb & Unterstützung und Überwachung“ – eingefügt, der den gesamten Lebenszyklus aller Ressourcen umfasst. Dabei steht das Ziel im Vordergrund, dass IT-Ressourcen kontrolliert geplant, entwickelt, implementiert sowie betrieben und überwacht werden. Diese vier übergeordneten Prozesse sind in insgesamt 34 kritische IT-Prozesse unterteilt, die für ein angemessenes Management der IT ausschlaggebend sind. Durch Berücksichtigung entsprechender Prozesse und Festlegung von Kontrollzielen werden die Ziele der Informationssicherheit im Unternehmen systematisch berücksichtigt.  167

ITACS Training AG, www.isaca.ch.

8.5 Anforderung an die Organisation und die Betriebsführung

223

Durch Audit-Richtlinien wird der Stand der Implementierung überprüfbar und im Rahmen des zugehörigen COBIT-Reifegradmodells mit sechs Reifestufen, z. B. nicht existent, definierter Prozess, optimiert, differenziert bewertbar sowie der Fortschritt in der Implementierung messbar.

8.5.1.8 ISO 27000 Der ISMS-Standard in ISO/IEC 27001:2005 wurde am 15. Oktober 2006 von der Internationalen Normungsorganisation (ISO) veröffentlicht! Er basiert auf BS 7799-2:2002 und wurde in ISO/IEC JTC1 SC 27 (dies ist das Komitee, das auch für ISO/IEC 17799 verantwortlich ist) entwickelt. Der Standard beschreibt die Anforderungen an ein Information Security Management System (ISMS) und ist, genau wie ISO 9001, ein Managementsystemstandard, nach dem auch zertifiziert werden kann. Zusätzlich zu der Entwicklung von ISO/IEC 27001 arbeitet ISO/IEC JTC1 SC 27 an weiteren Standards, die alle in der 27000-Serie zusammengefasst werden in Analogie zu anderen Managementsystemen, wie zum Beispiel ISO 9000. Die Standards in der 27000-Serie sind: x ISO/IEC 27000: Information security management system fundamentals and vocabulary (in Entwicklung), x ISO/IEC 27001: Information security management system – Requirements (veröffentlicht), x ISO/IEC 27003: Information security management system implementation guidance (in Entwicklung), x ISO/IEC 27004: Information security management measurement (in Entwicklung), x ISO/IEC 27005: Information security risk management (in Entwicklung). Andere Standards in der 27000-Serie werden auf dem nächsten SC27-Meeting diskutiert werden. Über die Aufnahme von ISO/IEC 17799:2005 in diese 27000Serie wird im Frühjahr 2007 entschieden werden; ein Vorwort in ISO/IEC 17799:2005 weist darauf hin, und wenn ISO/IEC 17799:2005 in die 27000-Serie integriert wird, wird der Standard die Nummer ISO/IEC 27002 erhalten. ISO/IEC 27001:2005 spezifiziert die Anforderungen an ein ISMS (Information Security Management System). ISO/IEC 27001 basiert auf BS 7799-2:2002 und ist mit anderen Managementstandards, namentlich ISO 9001:2000 und ISO 14001: 2004, harmonisiert. Dadurch ist es möglich, konsistente und integrierte Management-systeme zu implementieren. ISO/IEC 27001 beinhaltet außerdem das Plan-Do-Check-Act (PDCA-) Model als Teil des Managementsystemansatzes zur Entwicklung, Umsetzung und kontinuierlichen Verbesserung des ISMS. Die Umsetzung des PDCA-Modells implementiert die in der „OECD Guidelines for the Security of Information Systems and Networks“ zur Regelung der Sicherheit von Informationssystemen und Netzwerken beschriebenen Standards. Insbesondere liefert der Standard ISO/IEC 27001 ein robustes Modell zur Implementierung der Prinzipien dieser Richtlinien, zur Risikoanalyse, zum

224

8 Schlüsselfaktor IT-Sicherheit

Design und zur Implementierung von Sicherheitsmaßnahmen einschließlich Sicherheitsmanagement und beschreibt die Überprüfung der implementierten Maßnahmen.

8.5.2 Management des kontinuierlichen Geschäftsbetriebs Es sind korrigierende und vorbeugende Maßnahmen gegen Unterbrechungen von Geschäftsaktivitäten und Schutz der kritischen Geschäftsprozesse vor den Auswirkungen großer Ausfälle oder Katastrophen zu treffen. x Einhaltung der Verpflichtungen: Ziel von ISMS ist die Vermeidung von Verletzungen von Gesetzen des Straf- oder Zivilrechts, gesetzlicher, behördlicher oder vertraglicher Verpflichtungen und jeglicher Sicherheitsanforderungen. Weiter ist die Erfüllung organisationseigener Sicherheitspolitiken und Normen durch Systeme sicherzustellen. Audits des ISMS sind zu planen und zu vereinbaren, um das Risiko von Störungen der Geschäftsprozesse zu minimieren. x Der Aufbau des Managementrahmens: Mit der Übernahme des British Standard BS 7799 in die ISO 17799 wurde nur der erste Teil des BS 7799 „Leitfaden zum Management von Informationssicherheit“ auf die internationale Ebene gehoben. BS 7799 besitzt dagegen einen zweiten Teil „Spezifikation für Informationssicherheitsmanagementsysteme“, der einige ergänzende Informationen enthält. Die bedeutendste ist sicherlich der Abschnitt zur Schaffung des Managementrahmens. Grundsätzlich ist dabei anzumerken, dass dieser Managementrahmen nichts anderes ist als das Risikomanagementsystem, das jede Organisation besitzen sollte, um dem Phänomen der Unsicherheit zu begegnen. In Bezug auf das Management von Informationssicherheit werden im BS 7799, Teil 2, sechs Stufen angeführt.

8.5.2.1 Definition der Sicherheitspolitik Wie jedes Managementsystem benötigt auch der Managementrahmen des ISMS eine Sicherheitspolitik, um Ziele, Zwecksetzungen, Absichten und Hauptverantwortlichkeiten zu definieren.

8.5.2.2 Definition des Umfangs des ISMS Hier sind die Grenzen hinsichtlich der Merkmale der Organisation, ihres Standorts, ihrer Werte und ihrer Technologie festzulegen.

8.5.2.3 Risikoidentifikation und -analyse In diesem Schritt werden die Bedrohungen der Werte, die Schwachstellen und Auswirkungen auf die Organisation identifiziert und das Ausmaß des Risikos bestimmt (typischerweise als Wahrscheinlichkeit des Eintritts und Auswirkung im Fall des Eintritts).

8.5 Anforderung an die Organisation und die Betriebsführung

225

8.5.2.4 Risikomanagement Basierend auf dem notwendigen Bedarf an Sicherheit sind in dieser Stufe die Risikobereiche zu identifizieren.

8.5.2.5 Auswahl von Steuerungszielen und -maßnahmen Bezüglich der in Stufe 4. identifizierten Risikobereiche sind geeignete Zielvorgaben zu machen und entsprechende Maßnahmen zu treffen.

8.5.2.6 Erklärung der Anwendbarkeit Die ausgewählten Sicherheitsziele und Maßnahmen sowie die Gründe für ihre Auswahl sind in der Erklärung zur Anwendbarkeit zu dokumentieren.

8.5.3 Anforderungen an die Organisation und die Standards Die Aufnahme der IT-Sicherheit in die Unternehmensorganisation sollte eine strategische Entscheidung sein. Das Design und die Implementierung der ITSicherheit innerhalb der Organisation werden durch geschäftliche Anforderungen und Ziele bestimmt. Es ist zu erwarten, dass sich diese sowie deren unterstützenden Systeme im Verlauf der Zeit verändern. Einfache Situationen erfordern einfache IT-Sicherheitslösungen. Die Komplexität des Unternehmens soll auch beim Aufbau der IT-Sicherheit gespiegelt werden. Die IT-Sicherheitskultur muss sowohl als Attribut der Unternehmenskultur gesehen wie auch als Attribut des IT-Sicherheitsmanagements angesehen und von letzterem angetrieben werden. ISO 17799 und ISO 27000 machen eindringlich deutlich, dass es ohne ein systematisches Management der Informationen keinen wirksamen Schutz gibt. Mit der ISO 17799 und ISO 27000 gibt es internationale Standards, die als Basis für eine „Best Practice“ dienen können und global kommunizierbar sind. Die Zertifizierung nach BS 7799-Teil 2 und ISO 27000 wird insbesondere Organisationen helfen, die Kunden und anderen Stakeholdern darlegen möchten, dass Vertraulichkeit, Integrität und Verfügbarkeit von Informationen stets gewährleistet sind. Der Vorteil des internationalen Standards wird jedoch durch die fehlenden Festlegungen im operativen Maßnahmenbereich mehr als kompensiert. Für den Betrieb einer IT-Infrastruktur fehlen vollständig die operativen IT-Sicherheitsmaßnahmen für die aktuellen Betriebssysteme, das komplette Systemmanagement, der gesamte Bereich des Speichermanagements sowie die gesamte Speicherinfrastruktur mit SAN und NAS einschließlich der dort eingesetzten Switches. Im Schwerpunkt der folgenden Ausarbeitungen zu spezifischen IT-Sicherheitsmaßnahmen stehen die Aktivitäten der Planung und der Betriebsführung, die für das gesamte Aufgabengebiet IT-Sicherheit eine herausragende Bedeutung haben!

226

8 Schlüsselfaktor IT-Sicherheit

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur Backup, Archivierung und Speichernetz sind so unsicher wie jedes andere ungeschützte System. Dieser Satz muss nach den Erfahrungen der vergangenen Jahre jedem IT-Leiter Angst einjagen, wenn man bedenkt, dass jedes Unternehmen zur Existenz notwendige Informationen auf Datenträgern abgelegt hat, die sehr einfach eingesehen und gestohlen werden können. Nicht nur, dass Disaster Recovery und Datenklau keine extremen Herausforderungen darstellen, jetzt drohen weitere Gefahren durch Viren und Würmer. Dies gilt insbesondere für SAN- und NAS-Speichernetzwerke, die in Form von Campus-, Metropolitan Area Network (MAN-), Wide Area Network (WAN-) Netzwerken betrieben werden. Es ist zu vermuten, dass das Speichernetz die gleiche Lernphase wie das klassische Unternehmensnetz durchläuft mit DoS-Attacken (Denial-of-Service) und Einbrüchen ins Firmennetz.

8.6.1 IT-Sicherheitsmodelle unter Beachtung existierender Bedrohungsmuster Der erste Schritt eines jeden IT-Sicherheitskonzeptes und der Ableitung spezifischer Anforderungen ist eine genaue Bedrohungsanalyse. Aktuell sind bereits 25 verschiedene Angriffsmuster für Attacken aus dem Internet bekannt. Wem dies schon als sehr viel erscheint, der sei auf den Gefährdungskatalog des Bundesamts für Sicherheit in der Informationstechnik verwiesen, der in Summe 380 Gefährdungen auflistet, davon beschreiben allein 127 verschiedene vorsätzliche Handlungen (http://www.bsi.de/gshb/deutsch/g/g05.htm). Die wichtigsten Beispiele für Typen von Gefährdungen und vorsätzliche Handlungen sind (hier ohne Katalognummer):168 x Abschalten von Sicherheitsmechanismen, x Denial-of-Service-Attacken, x Flooding (hier MAC-Flooding), x Hijacking von Netz-Verbindungen, x Hoax, x Makro-Viren, x Manipulation von Managementparametern, x Maskerade, x Missbrauch von Fernwartungszugängen, x Missbrauch der Routing-Protokolle, x Phishing, x Sabotage; hier Beispiel des BSI, x Spoofing (ARP-, DNS- und IP-Spoofing), x Spyware, 

168

BSI, www.bsi.de/gshb/deutsch/g/g05.htm.

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur

x x x x

227

Trojanische Pferde, Unberechtigtes Kopieren der Datenträger, Verhinderung der Dienste Archivsystem, Viren, Würmer.

Abschalten von Sicherheitsmechanismen für den RAS-Zugang Die Sicherheit eines RAS-Zugangs hängt wesentlich von der korrekten Nutzung der angebotenen Sicherheitsmechanismen ab. … Denial-of-Service-Attacken Bereits seit einigen Jahren treten im Internet sog. „Denial-of-Service“-Angriffe (DoS) auf, die Schwachstellen in der Implementierung der Netzwerkfunktionalität verschiedener Betriebssysteme ausnutzen. Die zum Teil drastischen Auswirkungen auf die Verfügbarkeit der Zielsysteme – in Verbindung mit einer freien Zugänglichkeit der entsprechende Tools – erzwangen eine sehr zeitnahe Reaktion der Hersteller der Betriebssysteme und der Administratoren vor Ort. Die auch heute noch wirksamen Gegenmaßnahmen bestehen im Einspielen entsprechender Patches sowie der Aktivierung bzw. Installation von Paketfiltern auf vorgeschalteten IT-Sicherheitskomponenten. Denial-of-Service-Angriffe können gegen die angebotenen Dienste durchgeführt werden. Flooding (hier MAC-Flooding) MAC-Flooding ist eine Angriffsmethode, die die Funktionsweise eines Switches beeinflusst. Switches erlernen angeschlossene MAC-Adressen dynamisch. Die MAC-Adressen werden in der Switching-Tabelle gespeichert. Der Switch weiß dadurch, an welchen Ports die entsprechenden MAC-Adressen angeschlossen sind. Wenn nun eine angeschlossene Station mit Hilfe eines geeigneten Tools eine Vielzahl von Paketen mit unterschiedlichen Quell-MAC-Adressen sendet, speichert der Switch diese MAC-Adressen in seiner Switching-Tabelle. Sobald der Speicherplatz für die Switching-Tabelle gefüllt ist, sendet ein Switch sämtliche Pakete an alle Switch-Ports. Durch dieses „Fluten“ der Switching-Tabelle mit sinnlosen MACAdressen kann ein Switch nicht mehr feststellen, an welche Ports tatsächliche ZielMAC-Adressen angeschlossen sind. Diese Angriffsmethode wird verwendet, um das Mitlesen von Paketen in geswitchten Netzen zu ermöglichen. Es sind frei verfügbare Tools auf einschlägigen Seiten im Internet verfügbar, die auf einem Switch 155.000 MAC-Adress-Einträge innerhalb einer Minute erzeugen können. Hijacking von Netz-Verbindungen Weitaus kritischer als das Abhören einer Verbindung ist das Übernehmen einer Verbindung. Hierbei werden Pakete in das Netz eingeschleust, die entweder zum Abbruch oder Blockieren des Clients führen. Der Serverprozess kann daraufhin nicht erkennen, dass ein anderes Programm an die Stelle des Original-Clients getreten ist. Bei dieser Übernahme einer bestehenden Verbindung kann der Angreifer nach erfolgreicher Authentisierung einer berechtigten Person beliebige Aktionen in deren Namen ausüben.

228

8 Schlüsselfaktor IT-Sicherheit

Hoax Ein Hoax (englisch für Streich, Trick, falscher Alarm) ist eine Nachricht, die eine Warnung vor neuen spektakulären Computer-Viren oder anderen IT-Problemen enthält und Panik verbreitet, aber nicht auf realen technischen Fakten basiert. Meist werden solche Nachrichten über E-Mails verbreitet. Makro-Viren Mit dem Austausch von Dateien (z. B. per Datenträger oder E-Mail) besteht die Gefahr, dass neben der eigentlichen Datei (Textdatei, Tabelle etc.) weitere, mit dem Dokument verbundene Makros bzw. eingebettete Editorkommandos übersandt werden. Diese Makros laufen erst mit dem jeweiligen Anwendungsprogramm (Winword, Excel etc.) bei der Bearbeitung des Dokuments ab, indem der Benutzer das Makro aktiviert bzw. das Makro automatisch gestartet wird. Wird ein Dokument über einen WWW-Browser empfangen, der das Dokument automatisch öffnet, kann hierdurch ein (Auto-) Makro aktiviert werden. Da die Makrosprachen über einen sehr umfangreichen Befehlssatz verfügen, besteht auch die Gefahr, dass einem Dokument ein Makro beigefügt wird, das eine Schadfunktion enthält (z. B. einen Virus). Manipulation von Managementparametern Auch Managementsysteme können durch bewusst herbeigeführte Fehlkonfigurationen zu einem Angriff auf ein lokales Rechnersystem benutzt werden. Die Fehlkonfigurationen können dabei auf verschiedene Arten herbeigeführt werden. Dabei sind Manipulationen sowohl an der Managementplattform als auch an den verwalteten Geräten möglich. Insbesondere Netzmanagementsysteme, die SNMP benutzen, sind für Angriffe anfällig, bei denen bewusst Managementparameter fehlkonfiguriert werden (z. B. durch einen eigenen SNMP-Client). Je nach einstellbaren Parametern reichen die Attacken von einfachen „Denial-ofService-Attacken“ (z. B. durch Verstellen von IP-Adressen) bis hin zur Datenveränderung (z. B. nach Verstellen von Zugriffsrechten). Maskerade Die Maskerade benutzt ein Angreifer, um eine falsche Identität vorzutäuschen. Eine falsche Identität erlangt er z. B. durch das Ausspähen von Benutzer-ID und Passwort (siehe auch Unberechtigte IT-Nutzung), die Manipulation des Absenderfeldes einer Nachricht oder durch die Manipulation einer Adresse (siehe beispielsweise auch IP-Spoofing oder Web-Spoofing) im Netz. Weiterhin kann eine falsche Identität durch die Manipulation der Rufnummernanzeige (Calling Line Identification Presentation) im ISDN oder durch die Manipulation der Absenderkennung eines Faxabsenders (CSID – Call Subscriber ID) erlangt werden. Missbrauch von Fernwartungszugängen Bei unzureichend gesicherten Fernwartungszugängen ist es denkbar, dass Hacker Zugang zum Administrierungsport des IT-Systems erlangen. Sie können somit nach Überwindung des Anlagenpasswortes gegebenenfalls alle Administrations-

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur

229

tätigkeiten ausüben. Der entstehende Schaden kann sich vom vollständigen Anlagenausfall, über schwerste Betriebsstörungen, den Verlust der Vertraulichkeit aller auf der Anlage vorhandenen Daten bis hin zum großen direkten finanziellen Schaden erstrecken. Missbrauch der Routing-Protokolle Routing-Protokolle wie RIP (Routing Information Protocol) oder OSPF (Open Shortest Path First) dienen dazu, Veränderungen der Routen zwischen zwei vernetzten Systemen an die beteiligten Systeme weiterzuleiten und so eine dynamische Änderung der Routing-Tabellen zu ermöglichen. Es ist leicht möglich, falsche RIP-Pakete zu erzeugen und somit unerwünschte Routen zu konfigurieren. Der Einsatz von dynamischem Routing ermöglicht es, Routing-Informationen an einen Rechner zu schicken, die dieser in der Regel ungeprüft zum Aufbau seiner Routing-Tabellen benutzt. Dies kann ein Angreifer ausnutzen, um gezielt den Übertragungsweg zu verändern. Phishing Ein aktuell wichtiges Thema ist „Passwort-Fischen“ oder auch neudeutsch „Phishing“ genannt. Betrüger versuchen, mit Hilfe gefälschter E-Mails, gefälschter Webseiten und anderer Techniken an Authentisierungsinformationen zu gelangen, die sie dann nutzen, insbesondere um Geld von Bankkonten auf ausländische Konten zu transferieren. Betroffen sind im Prinzip alle wissensbasierten Authentisierungsverfahren, im Fokus steht hier das PIN-TAN-Verfahren, aber eben auch andere Passwort-Verfahren. Sabotage; hier Beispiel des BSI In einem großen Rechenzentrum führte die Manipulation an der USV zu einem vorübergehenden Totalausfall. Der Täter, er wurde ermittelt, hatte wiederholt die USV von Hand auf Bypass geschaltet und dann die Hauptstromversorgung des Gebäudes manipuliert. Der Totalausfall – insgesamt fanden in drei Jahren vier Ausfälle statt – führte partiell sogar zweimal zu Hardware-Schäden. Die Betriebsunterbrechungen dauerten zwischen 40 und 130 Minuten. Innerhalb eines Rechenzentrums sind auch sanitäre Einrichtungen untergebracht. Durch Verstopfen der Abflüsse und gleichzeitiges Öffnen der Wasserzufuhr entstehen durch Wassereinbruch in zentralen Technikkomponenten Schäden, die zu Betriebsunterbrechungen des Produktivsystems führen. Spoofing Verschiedene Sicherungsmechanismen auf der Netzebene (beispielsweise PortSecurity bei Switches) beruhen darauf, dass eine Verbindung nur von einem Gerät mit einer Adresse aufgebaut werden darf. Spoofing (hier ARP-Spoofing) Im Gegensatz zu einem Hub kann bei einem Switch grundsätzlich die Kommunikation zwischen zwei Stationen von keiner der anderen Stationen abgehört wer-

230

8 Schlüsselfaktor IT-Sicherheit

den. Zu diesem Zweck pflegt der Switch eine Tabelle, die die MAC-Adressen der beteiligten Stationen den verschiedenen Ports zuordnet. Datenpakete beziehungsweise Ethernet-Frames, die an eine bestimmte MAC-Adresse adressiert sind, werden nur an den Port weitergeleitet, an dem der betreffende Rechner angeschlossen ist. Doch nicht nur der Switch pflegt eine ARP-Tabelle, sondern auch die beteiligten Rechner. Ziel des ARP-Spoofings ist es, diese Tabellen zu manipulieren (ARP-Cache-Poisoning). Dazu schickt ein Angreifer eine ARPAntwort an das Opfer, in der er seine eigene MAC-Adresse als die des Routers ausgibt, der für das betreffende Subnetz als Standard-Gateway fungiert. Sendet das Opfer anschließend ein Paket zum eingetragenen Standard-Gateway, landet dieses Paket in Wirklichkeit beim Angreifer. Auf die selbe Weise wird der ARPCache des Routers so manipuliert, dass Ethernet-Frames, die eigentlich an das Opfer adressiert wurden, in Wirklichkeit beim Angreifer landen. Auf einschlägigen Internet-Seiten sind eine Reihe von Tools verfügbar, die diese Angriffsmethode ermöglichen. Spoofing (hier DNS-Spoofing) Um im Internet mit einem anderen Rechner kommunizieren zu können, benötigt man dessen IP-Adresse. Diese Adresse setzt sich aus vier Zahlen zwischen 0 und 255 zusammen, also zum Beispiel 194.95.176.226. Da solche Nummern nicht sehr einprägsam sind, wird einer solchen IP-Adresse fast immer ein Name zugeordnet. Das Verfahren hierzu nennt sich DNS (Domain Name System). So kann der WWW-Server des BSI sowohl unter http://www.bsi.bund.de als auch unter http://194.95.176.226 angesprochen werden, da der Name bei der Abfrage in die IP-Adresse umgewandelt wird. Die Datenbanken, in denen den Rechnernamen die zugehörigen IP-Adressen zugeordnet sind und den IP-Adressen entsprechende Rechnernamen, befinden sich auf so genannten Nameservern. Für die Zuordnung zwischen Namen und IP-Adressen gibt es zwei Datenbanken: In der einen wird einem Namen seine IP-Adresse zugewiesen und in der anderen einer IP-Adresse der zugehörige Name. Diese Datenbanken müssen miteinander nicht konsistent sein! Von DNS-Spoofing ist die Rede, wenn es einem Angreifer gelingt, die Zuordnung zwischen einem Rechnernamen und der zugehörigen IP-Adresse zu fälschen, d. h. dass ein Name in eine falsche IP-Adresse bzw. umgekehrt umgewandelt wird Spoofing (hier IP-Spoofing) IP-Spoofing ist eine Angriffsmethode, bei der falsche IP-Nummern verwendet werden, um dem angegriffenen IT-System eine falsche Identität vorzuspielen. Bei vielen Protokollen der TCP/IP-Familie erfolgt die Authentisierung der kommunizierenden IT-Systeme nur über die IP-Adresse, die aber leicht gefälscht werden kann. Nutzt man darüber hinaus noch aus, dass die von den Rechnern zur Synchronisation beim Aufbau einer TCP/IP-Verbindung benutzten Sequenznummern leicht zu erraten sind, ist es möglich, Pakete mit jeder beliebigen Absenderadresse zu verschicken. Damit können entsprechend konfigurierte Dienste wie rlogin benutzt werden. Allerdings muss ein Angreifer dabei u. U. in Kauf nehmen, dass er kein Antwortpaket von dem missbräuchlich benutzten Rechner erhält.

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur

231

Spyware Als Spyware werden Programme bezeichnet, die heimlich, also ohne darauf hinzuweisen, Informationen über einen Benutzer bzw. die Nutzung eines Rechners sammeln und an den Urheber der Spyware weiterleiten Trojanische Pferde Ein Trojanisches Pferd, oft auch (eigentlich fälschlicherweise) kurz Trojaner genannt, ist ein Programm mit einer verdeckten, nicht dokumentierten Funktion oder Wirkung. Der Benutzer kann daher auf die Ausführung dieser Funktion keinen Einfluss nehmen – insoweit besteht eine gewisse Verwandtschaft mit Computer-Viren. Es ist jedoch keine Selbstreproduktion vorhanden. Als Träger für Trojanische Pferde lassen sich alle möglichen Anwenderprogramme benutzen. Aber auch Scriptsprachen, wie Batch-Dateien, ANSI-Steuersequenzen, REXX Execs und ISPF Command Tables bei z/OS-Betriebssystemen, Postscript und Ähnliches, die vom jeweiligen Betriebssystem oder Anwenderprogramm interpretiert werden, können für Trojanische Pferde missbraucht werden. Die Schadwirkung eines Trojanischen Pferdes ist um so wirkungsvoller, je mehr Rechte sein Trägerprogramm besitzt. Unberechtigtes Kopieren der Datenträger Werden Datenträger ausgetauscht oder transportiert, so bedeutet dies unter Umständen, dass die zu übermittelnden Informationen aus einer gesicherten Umgebung heraus über einen unsicheren Transportweg in eine ggf. unsichere Umgebung beim Empfänger übertragen werden. Unbefugte können sich in solchen Fällen diese Informationen dort durch Kopieren einfacher beschaffen, als es in der ursprünglichen Umgebung der Fall war. Wegen der großen Konzentration schützenswerter Informationen auf Datenträgern elektronischer Archive (z. B. personenbezogene oder firmenvertrauliche Daten) stellen diese ein besonderes Angriffsziel für Diebstahl oder Kopie durch Unbefugte dar. Verhinderung der Dienste von Archivsystemen Wird die Indizierung von archivierten Daten verhindert oder gestört, z. B. durch die Angabe falscher Kontextdaten, so hat das unter Umständen zur Folge, dass Daten später gar nicht oder nur unter erheblichem Aufwand wieder gefunden werden können. Viren, Würmer Die Internet-Nutzung birgt zahlreiche Gefahren in sich. Wer seine Daten nicht schützt, macht es Angreifern einfach, diese bei der Übertragung mitzulesen, zu verändern oder sogar zu löschen. Man hört immer öfter von neuen Würmern oder Viren – Programmen also, die sich selbstständig verbreiten oder über EMails versandt werden und Schäden auf IT-Systemen anrichten können. Damit ein Virenangriff aber überhaupt stattfinden kann, benötigt das angreifende Programm in irgendeiner Art Zugang zu dem betroffenen System – entweder über eine Netzwerk- oder Telefonverbindung oder über Datenträger, wie Disketten, USB-Sticks oder CD-ROMs. Heutzutage stellt das Internet den bedeutendsten Verbreitungsweg dar.

232

8 Schlüsselfaktor IT-Sicherheit

„Die Planungs- und Lenkungsaufgabe, die erforderlich ist, um einen durchdachten und planmäßigen IT-Sicherheitsprozess aufzubauen und kontinuierlich umzusetzen, wird als IT-Sicherheitsmanagement bezeichnet. Die Erfahrung zeigt, dass es ohne ein funktionierendes IT-Sicherheitsmanagement praktisch nicht möglich ist, ein durchgängiges und angemessenes IT-Sicherheitsniveau zu erzielen und zu erhalten. Daher wird im BSI-Standard 100-1 „Managementsysteme für Informationssicherheit (ISMS)“ beschrieben, wie ein solches Managementsystem aufgebaut werden kann. Die Bausteine im IT-Grundschutz-Katalog enthalten jeweils eine Kurzbeschreibung für die betrachteten Komponenten, Vorgehensweisen und ITSysteme sowie einen Überblick über die Gefährdungslage und die Maßnahmenempfehlungen. Die Bausteine sind nach dem IT-Grundschutz-Schichtenmodell in die folgenden Kataloge gruppiert: x x x x x

B 1: Übergeordnete Aspekte der IT-Sicherheit, B 2: Sicherheit der Infrastruktur, B 3: Sicherheit der IT-Systeme, B 4: Sicherheit im Netz, B 5: Sicherheit in Anwendungen. Das IT-Sicherheitskonzept des BSI baut sich in Stufen auf:

x Schicht 1 umfasst die übergreifenden IT-Sicherheitsaspekte, die für sämtliche oder große Teile des IT-Verbunds gleichermaßen gelten. Dies betrifft insbesondere übergreifende Konzepte und die daraus abgeleiteten Regelungen. Typische Bausteine der Schicht 1 sind unter anderem IT-Sicherheitsmanagement, Organisation, Datensicherungskonzept und Computer-Virenschutzkonzept. x Schicht 2 befasst sich mit den baulich-physischen Gegebenheiten. In dieser Schicht werden Aspekte der infrastrukturellen Sicherheit zusammengeführt. Dies betrifft zum Beispiel die Bausteine Gebäude, Serverraum, Schutzschrank und häuslicher Arbeitsplatz. x Schicht 3 betrifft die einzelnen IT-Systeme des IT-Verbunds, die gegebenenfalls in Gruppen zusammengefasst wurden. Hier werden die IT-Sicherheitsaspekte sowohl von Clients als auch von Servern, aber auch von EinzelplatzSystemen behandelt. In diese Schicht fallen beispielsweise die Bausteine TKAnlage, Laptop sowie Client unter Windows 2000. x Schicht 4 betrachtet die Vernetzungsaspekte, die sich in erster Linie nicht auf bestimmte IT-Systeme, sondern auf die Netzverbindungen und die Kommunikation beziehen. Dazu gehören zum Beispiel die Bausteine Heterogene Netze, Modem sowie Remote Access. x Schicht 5 schließlich beschäftigt sich mit den eigentlichen IT-Anwendungen, die im IT-Verbund genutzt werden. In dieser Schicht können unter anderem die Bausteine E-Mail, Webserver, Faxserver und Datenbanken zur Modellierung verwendet werden.“169  169

BSI, www.bsi.de.

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur

233

Spätestens auf der Ebene 3 wird klar, dass das BSI mit seinem IT-Grundschutz-Konzept, so vorbildlich und ausführlich die Bedrohungsanalyse auch ist, so detailliert einzelne Maßnahmen im Maßnahmenkatalog auch beschrieben sind, keine ausreichende Antworten für die aktuelle Bedrohung, insbesondere im beschriebenen ILM-Umfeld bietet. So fehlen teilweise oder vollständig die Bausteine für die aktuellen Betriebssysteme (z. B. Win 2003, XP-Clients, Solaris 10 und die neuesten Unix-Derivate), das komplette Systemmanagement (z. B. Microsoft mit MOM, HP mit HPOpen-View, IBM Tivoli), der gesamte Bereich des Speichermanagements (z. B. IBM-Tivoli und EMC-Control-Center) sowie die gesamte Speicherinfrastruktur mit SAN und NAS einschließlich der aktuell dort eingesetzten Switches (z. B. Cisco- und Brocade-Switche). Ein weiterer entscheidender Nachteil ist die spezifisch deutsche Ausrichtung und damit die fehlende Anbindung an einen internationalen Standard, wie ihn im Bereich IT-Sicherheit ISO 17799 und in der Organisation ISO 20000 darstellen.

8.6.2 ISO 17799 und BS 7799 ISO 17799 umfasst die folgenden wichtigen Steuerungsbereiche (Controls), auf deren Basis geeignete Maßnahmen eingeleitet werden sollen, um deren Zielsetzungen sicherzustellen.

8.6.2.1 Sicherheitspolitik Die Sicherheitspolitik umfasst die strategische Ausrichtung und die Unterstützung der Geschäftsführung bei der Informationssicherheit. Eine dokumentierte und gelebte Sicherheitspolitik ist eine Kernvoraussetzung für den Erfolg des ISMS.

8.6.2.2 Organisation der Sicherheit Die Organisation der Sicherheit beinhaltet die Methoden und Verfahren zum Management von Informationssicherheit. Dies schließt auch die Sicherheit beim Zugang Dritter zu Informationen oder bei ausgelagerter Informationsverarbeitung (Outsourcing) ein.

8.6.2.3 Einstufung und Lenkung der Informationswerte Um Informationswerte zu schützen, bedarf es zunächst der Bestandsaufnahme, welche Informationswerte in einer Organisation gegeben sind (Inventur). Eine Klassifikation der Informationswerte hilft bei der Einstufung und Zuordnung von Schutzmaßnahmen.

8.6.2.4 Personelle Sicherheit Das Ziel der personellen Sicherheit ist es, die Risiken durch menschlichen Irrtum, Diebstahl, Betrug oder Missbrauch der Einrichtungen zu reduzieren. Die

234

8 Schlüsselfaktor IT-Sicherheit

Anwenderschulung ist ein außerordentlich wichtiger Aspekt, um ein Bewusstsein für Informationssicherheit zu schaffen und ein entsprechendes Verhalten zu fördern. Dazu gehört auch die Ausbildung für den Fall von Sicherheitsvorfällen und Störungen.

8.6.2.5 Physische und umgebungsbezogene Sicherheit Sicherheitszonen haben den Zweck, den unberechtigten Zugang, Beschädigung und Störung der Geschäftsräume und Informationen zu verhindern und vor Verlust, Beschädigung oder Kompromittierung von Werten und der Unterbrechung von Geschäftsaktivitäten zu schützen.

8.6.2.6 Management der Kommunikation und des Betriebs Dieser Steuerungsbereich dient x der Gewährleistung des korrekten und sicheren Betriebs von Geräten zur Informationsverarbeitung, x der Minimierung des Systemausfallrisikos, x dem Integritätsschutz von Informationen und Software, der Aufrechterhaltung der Integrität und Verfügbarkeit von Diensten zur Verarbeitung von Informationen und für die Kommunikation, x der Sicherung von Informationen in Netzen und dem Schutz der unterstützenden Infrastruktur, x der Verhinderung von Schäden an Werten und der Unterbrechungen des Geschäftsbetriebs und x der Verhinderung von Verlust, Änderung oder Missbrauch von Informationen, die zwischen Organisationen ausgetauscht werden.

8.6.2.7 Zugangskontrolle Die Zugangskontrolle steuert den Zugriff auf Informationen. Unautorisierter Zugriff auf das Informationssystem, auf Informationen, auf Anwendungen sowie auf das Computersystem sollen verhindert werden. Besondere Aufmerksamkeit gilt auch der Informationssicherheit beim Mobile Computing und der Telearbeit.

8.6.2.8 Systementwicklung und -wartung Bereits bei der Systementwicklung ist auf ausreichende Sicherheit zu achten. In Anwendungssystemen ist der Verlust, die Änderung oder der Missbrauch von Benutzerdaten zu verhindern. Kryptografische Maßnahmen sollen die Vertraulichkeit, Authentizität oder Integrität von Informationen schützen. Ferner ist sicherzustellen, dass IT-Projekte und Supportaktivitäten auf sichere Art und Weise durchgeführt werden. Auch bei der Wartung von Software und Informationen ist auf Sicherheit zu achten.

8.6 IT-Sicherheitsanforderungen für verteilte Infrastruktur

235

8.6.3 ITIL, BS 15000 und ISO 20000 ITIL – der aktuell weltweite De-facto-Standard im IT-Service – beschreibt den Wandel von der technisch orientierten IT-Abteilung zum kundenorientierten Dienstleister. ITIL ist die Abkürzung für den durch die CCTA (heute OGC) im Auftrage der britischen Regierung in den 80er Jahren des letzten Jahrhunderts und ständig stetig weiterentwickelten Leitfaden „IT Infrastructure Library“ mit „Best Practice”-Lösungen. ITIL beinhaltet eine umfassende fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. An der Entwicklung von ITIL waren IT-Dienstleister, Mitarbeiter aus Rechenzentren, Lieferanten, Beratungsspezialisten und Ausbilder beteiligt. U. a. deshalb bietet ITIL die Grundlage zur Verbesserung von Einsatz und Wirkung einer an den Geschäftsprozessen angepassten IT-Infrastruktur. Der aus ITIL abgeleitete British Standards BS 15000 war der erste weltweite Standard, der speziell das IT Service Management behandelte. BS 15000 beschreibt einen integrierten Satz von Managementprozessen für die Lieferung von Dienstleistungen. BS 15000 ist ausgerichtet an den Prozessbeschreibungen, wie sie durch die IT Infrastructure Library (ITIL) des Office of Government Commerce (OGC) beschrieben sind, und ergänzt diese komplementär. Mit ISO 20000, der Weiterentwicklung von ITIL und BS 15000, gibt es erstmalig einen weltweiten Standard, der speziell das IT Service Management behandelt. Mit der Umsetzung der definierten Prozesse (größtenteils noch auf Basis der ITIL-Beschreibungen) sind zumindest alle relevanten Prozesse des Betriebes einer IT-Infrastruktur definiert. Bezüglich spezifischer IT-Sicherheitsspezifikationen erbringt jedoch ISO 20000 keinen entscheidenden, zusätzlichen Input über die bereits vorgestellten Standards in ISO 17799 und in ISO 27000 hinaus.

8.6.4 CISA Das Certified Information System Auditor (CISA-) Programm der ISACA ist der De-facto-Standard im Bereich der Archivierung, des Managements und der Sicherheit der eingesetzten IT-Prozesse. Das CISA-Audit stellt die revisionsgerechte Durchführung aller IT-Aktivitäten sicher.

8.6.5 Weitere Standards für spezifische Sicherheitsaspekte SP 800-14 SP 800-27 IS 13569 IS 13335 IS 18044

Generally Accepted Principles and Practices for Securing Information Engineering Principles for Information Technology Security Banking and Related Financial Services – Information Security Guide Guidelines for Management of IT-Security (GMITS) bzw. Management Information Security Incident Management – Capability Maturity Model

236

8 Schlüsselfaktor IT-Sicherheit

8.6.6 Physikalische Sicherheit BSI 7500 Produkte für die materielle Sicherheit EN 1047-1 / -2 Wertbehältnisse Klassifizierung und Methoden zur Prüfung des Widerstandes gegen Brand DIN 4102 Brandverhalten von Baustoffen und Bauteilen EN 60529 Schutzart durch Gehäuse EN 1143-1 Widerstandsgrad EN 1627 Fenster, Türen, Abschlüsse Einbruchhemmung DIN 18095 Rauchschutztüren FIPS 140-2 Security Requirements for Cryptographic Modules ITSEC Information Technology Security Evaluation Criteria CC Common Criteria

8.7 Backup als Teil einer IT-Sicherheitsstrategie 8.7.1 Stand Backup-Sicherheit Eine Umfrage von Network Appliance zur Datensicherheit und zum Backup ergab zum Teil erschreckende Antworten: „Lediglich 10 Prozent der Deutschen IT-Experten halten demzufolge ihre Daten für absolut sicher und sind damit am misstrauischsten. Mit 19 Prozent haben die Österreicher das höchste Vertrauen in die Sicherheit ihrer Daten. Bei den Schweizern sind es 13 Prozent. Knapp 75 Prozent der Deutschen schätzten das Ausmaß der Datensicherheit auf 85 bis 99 Prozent – und sehen damit im Schnitt einen von 10 Datenunfällen als irreparabel an. Diese Einschätzung kommt nicht von ungefähr: Knapp die Hälfte der Teilnehmer war bereits Opfer einer Sicherheitspanne und musste Datenverluste verschmerzen. Bedrohungen der Datensicherheit kommen für die meisten Teilnehmer sowohl aus den eigenen Reihen als auch von extern. Interessanterweise ist die Gefahr eines Datenverlusts aus dem Kollegenkreis für 38 Prozent reeller als die von außen. Lediglich 16 Prozent sehen ihre Daten allein durch externe Bedrohungen in Gefahr.“170 Jedes Jahr fragen das Computer Security Institute (CSI) und das FBI USamerikanische Unternehmen nach finanziellen Schäden, die sie durch Computerkriminalität erlitten haben. Der aktuelle Report (Computer Crime and Security Survey 2005) berichtet von einem bemerkenswerten Trend: Während der angegebene Verlust insgesamt rückläufig ist, hat er sich in den Kategorien „Unautorisierter Datenzugriff“ und „Diebstahl geheimer Daten“ gegenüber 2004 versechsfacht bzw. verdreifacht. Man gelangt offenbar leicht an sensible Informationen, und ihr Missbrauch hat für das Unternehmen ernstere Konsequenzen  170

Network Appliance, www.drchip.de/html/bis_12_september_2006.html.

8.7 Backup als Teil einer IT-Sicherheitsstrategie

237

denn je.171 Das zeigen schon gängige Backup-Strategien, bei denen die Zugriffssicherheit der Informationen in der Regel nachrangig ist. Sicherungsbänder aber können verlegt und gestohlen werden oder etwa beim Transport zwischen Rechenzentrum und Lagerungsort verloren gehen. Sind die Informationen auf den Backup-Medien nicht weiter geschützt, liegen sie wie ein offenes Buch da. Jeder kann fast eine beliebige Anzahl von Beispielen bringen, in denen das Backup nicht direkt, sondern erst nach erfolgreichen Kniffen usw. vollständig erfolgreich war bzw. alle Versuche erfolglos beendet werden mussten. Die beiden Autoren verzichten daher auf weitere Beispiele.

8.7.2 Datenspeicherungs- und Backup-Lösungen Traditionelle Datenspeicherungs- und Backup-Lösungen machen keinen Unterschied zwischen Datentypen. Sie repräsentieren eine Art Einheitslösung, die Speicher, Replizierung, Backup und Datenlöschung exakt gleich behandelt. Der erste Schritt ist die Klassifizierung der Daten nach ihrem Typ und die Zuordnung dieser Klassifizierungen auf die korrespondierenden primären und sekundären Backup-Speicherklassen in Abstimmung mit den geschäftlichen Anforderungen. Es wird dabei unterschieden, ob es sich um die dauerhafte Aufbewahrung von Compliance-Daten handelt, um ökonomischen Online-Zugriff auf Speicher oder um das Löschen von Daten. Noch wichtiger ist die kontinuierliche Neubewertung der Daten, da ihr Wert in Abhängigkeit von den jeweiligen Geschäftsanforderungen im Lauf der Zeit schwankt. Um die Daten möglichst automatisiert dem passenden Speicher zuordnen zu können, muss einerseits eine Datenklassifizierung gemäß Typ, Besitzer, Größe, Zeitpunkt der letzten Änderung und ComplianceBedarf erfolgen. Die Aufgabe des Backups auch im Rahmen eines ILM-Konzeptes ist der Schutz der Informationen. Hierzu werden definierte Datenbereiche, die so genannten Informationsobjekte, aufgrund der definierten geschäftspolitischen Policies gesichert und im Mittelfristzeitraum gemäß SLA bereitgestellt. Technologische Basis für eine ILM-konforme Backup-Umgebung ist daher eine vernetzte, mehrstufige Speicherlandschaft, die je nach Bedarf Konzepte wie Storage Area Networks (SANs), Network Attached Storage (NAS) oder Content Addressed Storage (CAS) einschließt. Auch Bereiche wie Enterprise Content Management (ECM), Hierarchical Storage Management (HSM) können Bestandteile eines ILM-Konzepts sein. In der Praxis muss eine ILM-Lösung vier Kriterien erfüllen: x Die intelligente Klassifizierung der Daten. x Die intelligente Zuordnung der jeweiligen Datenklasse auf die passende Speicherklasse. x Der notwendige Schutz der jeweiligen Datenklasse in Form einer auf die Speicherklasse passenden Backup-Policy. x Eine offene Architektur, die ILM-Elemente aus Enterprise-Content-Management, Data-Movement und primärem/sekundärem Speicher kombinieren kann. 

171

Computer Security Institute-Pressemitteilung, www.gocsi.com.

238

8 Schlüsselfaktor IT-Sicherheit

Eine entsprechende primäre und sekundäre Speicherplattform sollte einen offenen Ansatz pflegen und die verschiedenen Speicherklassen konsolidieren. Sie sollte einen sicheren Zugriff bieten, Backup-, Restore- und Disaster-Recovery-Anforderungen beachten. Damit haben Unternehmen die freie Wahl der Komponenten, die ihre Anforderungen am besten abdecken. Wie bereits beschrieben, gibt es viele Sicherheitsaspekte, die im Umfeld von ILM zu beachten sind. Daher sollte Teil eines ILM-Konzepts immer auch eine Betrachtung nach Sicherheitsaspekten und Sicherheitsstandards sein. Die Verwaltung von Speicher und Backup ist eine komplexe Materie, die sich jedoch mit der richtigen Information-Lifecycle-Management-Strategie vereinfachen lässt. Die jeweils optimale Balance zwischen Speicherressourcen und Sicherung der Daten setzt die individuelle Definition von Daten-, Speicher- und Backup-Klassen voraus, in die Faktoren wie Kosten, Produktivität, Geschäftsziele, Regulierungen, Sicherheit oder Performance einfließen sollten (siehe Klassifizierungsmodelle). Darauf aufbauend folgt die automatische Klassifizierung bestehender und neuer Daten, deren Ergebnis über weitere Schritte wie etwa Sichern, Verschieben oder Löschen entscheidet und die regelbasiert kontinuierlich wiederholt wird. Auf diese Weise erhalten die Daten während ihres gesamten Lebenszyklus das richtige Maß an Schutz und Verfügbarkeit. Ihr Nutzwert für das Unternehmen steigt und die damit verbundenen Speicherkosten sinken, da Ressourcen besser ausgelastet und zielgerichtet eingesetzt werden können. Für die Umsetzung einer ILM-Strategie müssen für jeden der drei Bereiche x Speicherressourcenmanagement, x Compliance bzw. Datensicherheit und x Migration die optimalen Lösungen ausgewählt werden. Die Kompatibilität der einzelnen Bausteine kann nicht groß genug eingestuft werden.

8.7.3 SLA als Kernforderung für den Backupund Wiederherstellungsprozess Nur das SLA (Service Level Agreement) definiert die spezifischen Anforderungen an das Backup im Allgemeinen, an die Backup-Klassen im Spezifischen und den darauf aufbauenden Wiederherstellungsprozess im Bedarfsfall. Applikationen werden im Allgemeinen in solche mit wahlfreien oder sequenziellen Zugriffsmustern unterschieden. Randomisierter Datenzugriff wird in I/O pro Sekunde (IOPS) beschrieben bzw. gemessen und findet sich vor allem bei Applikationen wie Online Transaction Processing (OLTP) und Decision Support (DS). Sequenzieller Datenzugriff wird in MByte/s gemessen und ist bei bandbreitenintensiven Applikationen wie Media-Streaming und der Verarbeitung seismischer Daten zu finden. Diese beiden Profile unterscheiden sich erheblich in ihren Anforderungen an das Speichersystem. Während Controller und Firmware eine sehr wichtige Rolle spielen, sollte die Bedeutung des Laufwerks nicht unterschätzt werden.

8.7 Backup als Teil einer IT-Sicherheitsstrategie

239

8.7.4 Wiederherstellungsprozess Bei der obigen Umfrage zum Thema der Wiederherstellung verlorener Daten gingen die Meinungen auseinander: 47 Prozent der deutschen IT-Experten würden zwei Stunden als Limit für die Wiederherstellung ihrer Daten akzeptieren, 43 Prozent geben sich sogar mit einem Tag Wiederherstellzeit zufrieden. 10 Prozent hätten ihre Daten gerne binnen fünf Minuten wieder zurück – ebenso wie je 4 Prozent der Schweizer und Österreicher. Über die Dauer der Rücksicherung entscheidet auch die Art des Datenspeichers. Sicherheitskopien von Daten auf Festplatten werden traditionell auf Magnetbandkassetten gespeichert. Die Umfrage ergab, dass sich 22 Prozent der deutschen Teilnehmer nicht mehr ausschließlich auf die klassische Bandsicherung verlassen und zusätzlich auch Festplatten für das Daten-Backup nutzen. Beim Einsatz der Festplatte als BackupMedium bilden deutsche Firmen hier übrigens das Schlusslicht: Während bei den Österreichern 37 Prozent beide Speichermedien nutzen, sind es bei den Schweizern bereits 60 Prozent. „Die Einschätzung des Grads an Datensicherheit entspricht keineswegs dem heutigen Stand der Speichertechnik“, so Manfred Reitner, Area Vice President Germany bei Network Appliance. „Das ist wie bei einer gefühlten Temperatur, die selten mit der Anzeige des Thermometers übereinstimmt. Als Hersteller von Datenspeichern wissen wir sehr gut, was technisch machbar ist. Das Wiederherstellen einer fast beliebigen Menge Daten ist heute eine Sache von Sekunden und eine mehrstufige Backup-Strategie aus Festplatte und Band sichert gegen Datenverlust ab. Manch ein Datensicherheitskonzept kann mit Sicherheit noch verbessert werden.“172 Auch diese Ergebnisse sind erschreckend, da erst garantierte Wiederherstellzeit, hohe Netzverfügbarkeit und QoS-Parameter (Quality-of-Service) auf Basis individueller Vereinbarungen (SLAs) mit dem Kunden hohe Effektivität und Wirtschaftlichkeit der Geschäftsabläufe sichern. Nur eine Datenklassifizierung im Rahmen von ILM schafft die Voraussetzung, zeitkritische Anwendungen z. B. aus einem Trader-Bereich, Sprach- oder Videodaten gegenüber zeittoleranten Daten wie E-Mail-Anwendungen bevorzugt bei Verlust der Daten wiederherzustellen. Eine zügige Wiederherstellung gelingt jedoch nur dann zuverlässig, wenn u. a. folgende Bedingungen erfüllt sind: x Das Wiederherstellen des Systems muss ohne weit reichende Kenntnisse über die Interna dieses Systems durchführbar sein. x Die Wiederherstellung sollte nicht zu stark von einer bestimmten Hardwarekonfiguration abhängen. x Das Recovery sollte ohne Benutzerinteraktion – und somit mit weniger Fehlermöglichkeiten – ablaufen. Jeder Datenverlust bedeutet, dass ein IT-Service nicht in der notwendigen Qualität bereitgestellt werden konnte. Dem Online-Datenschutz kommt daher eine Schlüsselfunktion zu, um einen unterbrechungsfreien Betrieb sicherzustel

172

Network Appliance, www.drchip.de/html/bis_12_september_2006.html.

240

8 Schlüsselfaktor IT-Sicherheit

len. Er ist besonders wichtig, um den Geschäftsbetrieb in dem Zeitraum aufrechtzuerhalten, der für die Wiederherstellung nach einem „data loss“ benötigt wird. Dies ist annähernd ebenso wichtig wie die Band-Backups selbst. Gemäß der hohen Bedeutung der Datenverfügbarkeit im Rahmen einer ILM-Strategie muss für jede der definierten Backup-Klassen eine eigene Strategie entwickelt werden, die sich aus der Kombination der Medien Festplatte und Band zusammensetzt.

8.7.5 Backup-Medium Festplatte SATA- und FC-Laufwerke weisen vollkommen unterschiedliche Leistungsprofile auf. FC-Platten wurden für höchste IOPS und MByte/s-Leistungsraten entwickelt. Sie integrieren moderne Technologien, um Rotationsgeschwindigkeiten und Datenübertragungsraten zu maximieren und zeitgleich Suchzeiten sowie Latenz zu mindern. Darüber hinaus ist die FC-Schnittstelle robust genug, parallel und bi-direktional viele I/O-Operationen unterschiedlichster Größe abzuarbeiten. Der langsamere Laufwerksmechanismus von SATA und eine limitierte Schnittstellenfunktionalität führen zu einer geringeren IOPS und Datentransferrate im Vergleich zu FC. Während diese Einschränkungen SATA für die meisten leistungsorientierten, transaktionsbasierten (IOPS) Applikationen ausschließen, spielen diese in bandbreiteorientierten Anwendungen eine weitaus geringere Rolle – hier ist SATA in vielen Fällen die richtige Wahl. Ein letztes Kriterium ist die Zugriffshäufigkeit. Auf den ersten Blick erscheinen Implementationen von Sekundärspeichern, die randomisierten Datenzugriff generieren, nicht für SATA-Platten geeignet. Allerdings wird auf fixe und Referenzdaten nur sporadisch, dann aber umfangreich zugegriffen. Kosten werden hier pro GByte und nicht nach Leistung betrachtet. Wichtig ist die korrekte Nutzung der SATA-Platten. Lebensdauer und Ausfallquoten werden immer mit Bezug zu einem Duty-Cycle angegeben. Er legt fest, von welcher Nutzung bei einer Harddisk ausgegangen wird. Alle weiteren Parameter sind nur bei diesem Duty-Cycle gültig. Die Zahl gibt mitnichten den empfohlenen Anteil der Laufzeit auf 24 Stunden gerechnet an. Mit Duty-Cycle wird der Anteil der Plattenzugriffe über 24 Stunden definiert, bei dem sich die Mechanik des Laufwerks bewegt, also Such-, Lese- und Schreibzugriffe. Die Zeit, in der das Drive unbenutzt rotiert, zählt nicht dazu. Das führt zu Anwendungen, für die SATA-Platten besonders geeignet sind, und andere, die besser mit FC- und SCSI-Festplatten abgedeckt werden. Dies gilt insbesondere für alle Applikationen, die mit einer hohen Zahl von nicht sequenziellen Zugriffen ablaufen. Die große Menge an mechanischen Zugriffen beim ständigen Neupositionieren der Köpfe treibt den DutyCycle in die Höhe. Auch die Drehzahl spricht bei transaktionsintensiven Anwendungen für FC oder SCSI. Diese Platten erreichen in der Regel 10.000 oder 15.000 U/min während SATA-Disks meist nur mit 7.200 Umdrehungen betrieben werden. Die bedeutet insbesondere auch, dass sich die durchschnittliche Zeit pro Suchvorgang verdoppelt. Dies hat insbesondere bei ständigen Leseoperationen enorme Auswirkungen auf die Performance der Applikation.

8.7 Backup als Teil einer IT-Sicherheitsstrategie

241

Abb. 8.2. Festplatten und Tapes im Vergleich173

8.7.6 Backup-Medium Band Allein aufgrund des Kostenvorteils sind im Backup-Bereich häufig Bandsysteme im Einsatz. Der primäre Vorteil eines Tapes im Vergleich zu einer Festplatte liegt neben den Kosten in der Möglichkeit, sie sehr einfach zu transportieren. Dieser Vorteil verliert jedoch aktuell schnell an Bedeutung durch die zunehmenden Möglichkeiten, sehr kostengünstig Daten online über weite Distanzen zu spiegeln.

8.7.7 Verschlüsselung des Backups als IT-Sicherheitsstrategie Die Notwendigkeit zur Verschlüsselung der Daten, insbesondere auf den Backup-Medien, haben die beschriebenen Beispiele bereits untermauert. Nur wenn die Backup-Daten sicher verschlüsselt sind, ist der Diebstahl des Mediums oder der Versuch einer Manipulation aus dem Unternehmen heraus sicher ohne Folgen. Dank der Verschlüsselung kann der Inhalt nicht mehr gelesen werden. Datensicherheit für Backup-Vorgänge ist nur über Verschlüsselung der Daten möglich. Viele Unternehmen schrecken jedoch vor dem Verschlüsseln der Daten zurück, da sie den hohen Administrationsaufwand und unverhältnismäßige  SNW, a.a.O.

173

242

8 Schlüsselfaktor IT-Sicherheit

Eingriffe in die Sicherungsabläufe fürchten. Bedenken, ob die chiffrierten Daten tatsächlich sicher sind, werden ebenfalls häufig geäußert.

8.7.7.1 Sicheres Verschlüsselungsverfahren Der seit einigen Jahren etablierte Advanced-Encryption-Standard (AES) gilt als besonders sicher. AES ist eine Blockchiffre, das heißt, die Daten werden vor der Verschlüsselung in Blöcke unterteilt. Jeder Block wird in verschiedenen Runden mit dem Schlüssel chiffriert, wobei sich die Anzahl der Runden aus Schlüssellänge und Blockgröße ergibt. Diese Werte sind voneinander unabhängig und können jeweils 128, 192 und 256 Bit betragen. Bei 128-Bit-Schlüsseln und 128Bit-Blöcken gibt es zehn Runden, bei 256-Bit-Schlüsseln und 192 Bit-Blöcken 14. Beim Entschlüsseln werden die Operationen der einzelnen Runden in umgekehrter Reihenfolge durchgeführt. Meldungen, dass eine bestimmte Schlüssellänge mit handelsüblicher Hardware geknackt wurde, erfordert eine ständige Anpassung der Schlüssellänge.

8.7.7.2 AES-Algorithmus II Da der dem AES-Verfahren zugrunde liegende Riijndael-Algorithmus bislang keine mathematischen Lücken offenbart hat, lässt er sich nur über Brute-ForceAngriffe knacken, d. h. durch Ausprobieren aller möglichen Buchstaben- und Zahlenkombinationen. Ist der Schlüssel 128 Bit lang, würde ein Rechner selbst bei elf Tera-Versuchen pro Sekunde (11 u 1012, entspricht dem aktuellen Leistungsvermögen der Dechiffrier-Maschine „Deep Crack“) 1018 Jahre benötigen, um alle Varianten durchzuspielen. Selbst wenn die richtige Kombination ein paar Jahre früher gefunden wird, ist der Algorithmus nach menschlichem Ermessen zurzeit sicher.

8.7.7.3 Verschlüsselung am besten in der Virtual-Tape-Library Es bleibt der andere häufig geäußerte Vorbehalt, dass Datenverschlüsselung die Performance der Backup-Vorgänge übermäßig strapaziert. Sicher kostet es CPULeistung, wenn alle Daten vor dem Transfer durch den Krypto-Algorithmus geschickt werden. Moderne CPUs sind dem Rechenaufwand zwar gewachsen, aber nur, wenn sie keine anderen Aufgaben parallel abarbeiten müssen. Das ist aber keine hinreichende Begründung, ganz auf die Verschlüsselung bei BackupProzessen zu verzichten. Die Frage ist vielmehr, wo sie am besten durchgeführt wird. In Backup-Architekturen mit Virtual Tape Library (VTL), die immer mehr Verbreitung finden, bietet sich dafür die VTL-Instanz selbst an. Eine VTL kombiniert die Vorteile von Tape- und Disk-Backup, indem sie beliebige Datensicherungsumgebungen als virtuelle Backup-Volumes auf Festplattensystemen konsolidiert. Die Disks präsentieren sich den Backup-Hosts dabei als flexibel verfügbare Tape-Drives. Entsprechende Lösungen lassen sich in der Regel ohne größere Eingriffe in vorhandene Sicherungsstrukturen integrieren und sind für

8.7 Backup als Teil einer IT-Sicherheitsstrategie

243

alle gängigen Third-Party-Backup-Applikationen und Policies transparent. Ein weiteres Plus ist die Leistungsstärke: VTL-Lösungen bringen heute Durchsatzraten mit, die ein Vielfaches über denen traditioneller Bandbibliotheken liegen. Verschlüsselungsprozesse können diese hohe Leistungsfähigkeit nicht so verringern, dass die regulären Backup-Vorgänge ernsthaft beeinträchtigt werden. Verschlüsselungsfunktionen können auch in Secure Tape Transport Service (STTS) direkt in das Export/Import-Subsystem seiner VTL-Lösung integriert werden. Damit werden die Backup-Produktivsysteme nicht mit den Chiffriervorgängen belastet.

8.7.7.4 Authentizität der Daten Bei der Verwendung eines asymmetrischen Verfahrens kann zusätzlich die Authentizität der Daten sichergestellt werden. Bei asymmetrischen Kryptosystemen besitzt der Anwender zwei Schlüssel. Der erste Schlüssel, der öffentliche Schlüssel (Public Key), dient dazu, die eigenen Daten zu verschlüsseln. Erst mit dem zweiten Schlüssel, dem geheimen Schlüssel (Secure Key oder Privat Key), können die Daten im Bedarfsfall wieder gelesen werden. Diese Tatsache wird u. a. bei der elektronischen Unterschrift genutzt, da nur der Besitzer des geheimen Schlüssels einen Hash-Wert besitzt, der das Dokument identifizieren und chiffrieren kann. Der Hash-Wert des Dokumentes wird vom Empfänger der Nachricht errechnet und mit dem chiffrierten Hash-Wert, der mit dem öffentlichen Schlüssel dechiffriert werden kann, auf Übereinstimmung geprüft. Nur wenn beide Hash-Werte gleich sind, ist sichergestellt, dass der Ersteller des Backups im Besitz des geheimen Schlüssels ist und das Backup nicht manipuliert wurde.

8.7.7.5 Schlüsselverwaltung Die Daten zu verschlüsseln ist eine Sache, die Schlüssel zu verwalten eine andere. Dieser Punkt bereitet Administratoren in der Regel das meiste Kopfzerbrechen, und das hat zwei Gründe: die Anzahl der Schlüssel und die Schlüsselübertragung. Im Fall der Chiffrierung von Backup-Daten spielt der erste Faktor allerdings eine geringere Rolle, denn da die Kommunikation beim Backup auf eine überschaubare Zahl „Teilnehmer“ beschränkt ist – die Speicherorte, zwischen denen die Daten transportiert werden –, hält sich die Menge der zu administrierenden Schlüssel in Grenzen. Beim Schlüsseltransport dagegen ist einiges mehr zu beachten. Der sicherste Algorithmus ist wertlos, wenn der Schlüssel verloren geht oder ungeschützt über einen unsicheren Kanal übertragen wird. Gängige Transportwege wie LAN, WLAN und Internet bieten viele Möglichkeiten, von außen einzugreifen, etwa per Man-in-the-Middle-Attacke. Der Angreifer erlangt zum Beispiel die Kontrolle über einen Router und leitet den Datenverkehr um. Sind Angreifer und Opfer im gleichen lokalen Netz, kann die Umleitung auch über eine Modifikation der ARP-Tabellen erfolgen (Ethernet-Protokoll für die Zuordnung von Internetund Hardwareadressen). Auch SSL-verschlüsselte Verbindungen sind nicht von Haus aus sicher. Ohne Austausch digitaler Zertifikate zwischen Sender und Emp-

244

8 Schlüsselfaktor IT-Sicherheit

fänger kann ein Dritter bei der ersten SSL-Verbindung falsche Schlüssel unterschieben und den Datenverkehr mitlesen. Verschlüsselungskonzepte für BackupDaten müssen also auch Vorkehrungen für die sichere Schlüsselübertragung enthalten. Eine sinnvolle Option ist ein spezielles Passwortsystem für die Schlüssel, das gängigen Angriffsmustern Stand hält, zum Beispiel einer WörterbuchAttacke. Sie fußt auf der Überlegung, dass die meisten Passwörter aus sinnvollen Zeichenkombinationen bestehen, die von der angreifenden Instanz nacheinander ausprobiert werden. Passwörter müssen also so „unlogisch“ zusammengesetzt sein, dass sie nicht auf einfache Weise geknackt werden können.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie 8.8.1 Beispiele für den Bedarf an einer Disaster-Recovery-Lösung Ein eindringliches Beispiel für die Bedeutung des Disaster Recovery ist die WTC-Katastrophe am 11. September 2001. Bei den direkt oder indirekt involvierten Unternehmen gingen etwa 30 Prozent der Geschäftsdaten unwiederbringlich verloren, da kein Backup existierte oder rechtzeitig an einen anderen Standort ausgelagert wurde. Von den Kunden, die externe Bandarchive besaßen, verfügten nur die wenigsten über Dokumentationen, die den Inhalt der Bänder beschrieben. Die Unternehmen, die in den Stunden nach dem Anschlag die Situation beherrschten, hatten alle einen kontinuierlichen Online-Zugang zu den extern verwahrten Kopien ihrer Produktionsdaten. Diese Zweit- oder gar Drittkopie der kritischen Daten wurden kontinuierlich in Echtzeit von den eingesetzten Replikationstechnologien erstellt. Probleme in der IT-Serviceserbringung oder im Umfeld des IT-Standortes können zum Ausfall eines Standortes oder der gesamten IT führen, dem so genannten Desaster- bzw. Katastrophen-Fall oder „Disaster Recovery Case“. Von der Disziplin „Disaster Recovery“ wird selbstverständlich erwartet, dass sie mit dem Wachstum und der weltweiten Struktur der Unternehmen Schritt hält. Zu den treibenden Kräften der Steigerung der Anforderungen zählen vor allem neue Technologien, ein Geschäftsbetrieb ohne Ladenschluss in allen Branchen und die Globalisierung. Viele Services, wie z. B. der 24u7-Zugang für den Kunden, waren in der Vergangenheit einfach nicht durchführbar. Dazu kommt die immer intensivere Vernetzung von Unternehmen. Sie erhöht die Verwundbarkeit noch zusätzlich, denn Ausfälle bei einem Unternehmen können schnell gewaltige Auswirkungen auf Geschäftspartner haben. Beim Management der Informationsverfügbarkeit hat die Globalisierung zu vielfältigen Problemen geführt. Eine Rund-um-die-Uhr-Verfügbarkeit an 365 Tagen pro Jahr stellt die sowieso knapp besetzten IT-Abteilungen auf eine harte Probe. Ein BackupZeitfenster ist in vielen Fällen nicht mehr tragbar, was eine besondere Heraus-

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

245

forderung für jeden CIO darstellt, sollen doch die wertvollen Datenbestände zuverlässig geschützt und die Applikationen regelmäßig gewartet werden. Dazu kommt die in den letzten 15 Jahren massiv gestiegene Komplexität und Heterogenität der Infrastrukturen. Immer mehr verschiedene Technologien müssen nahtlos zusammenarbeiten. Anwendungen werden umfangreicher, Data Warehouses generieren z. B. eine immer größere Menge von Geschäftsdaten. Regionale Datenzentren von Niederlassungen schießen aus dem Boden, von denen jedes seine eigenen Business Continuance (BC-) und Disaster Recovery (DR-) Systeme benötigt. Diese wiederum müssen mit den Strategien der Zentrale koordiniert werden. Zur gestiegenen Komplexität trägt auch die Tatsache bei, dass sich viele Organisationen – trotz einer Fülle modernster Technologien für neue Speichermedien – immer noch auf Bänder als primäres Backup-Medium verlassen. Das BSI zum Thema Katastrophenfall: „Bei einem Brand in einem chemischen Betrieb in unmittelbarer Nähe eines Rechenzentrums (ca. 1000 m Luftlinie) entstand eine mächtige Rauchwolke. Das Rechenzentrum besaß eine Klima- und Lüftungsanlage, die über keine Außenluftüberwachung verfügte. Nur durch die Aufmerksamkeit eines Mitarbeiters (der Unfall geschah während der Arbeitszeit), der die Entstehung und Ausbreitung verfolgte, konnte die Außenluftzufuhr rechtzeitig manuell abgeschaltet werden.“ 174 Vor dem Hintergrund derartiger Anforderungen und Erfahrungen definieren wir Disaster Recovery (DR) als die komplette Wiederherstellung eines Standorts und der ausgefallenen Infrastruktur nach einem Katastrophenfall. Dazu gehören der Wiederaufbau der IT-Infrastruktur, die Wiederherstellung der Daten sowie der Neustart der Anwendungen und Netzwerke, die für den Geschäftsbetrieb notwendig sind. Die Business Continuity (BC-) Planung umfasst die Einrichtung eines temporären Betriebsstandortes, einer „Hot Site“. Typischerweise wird in der Hot Site eine Kopie der Produktionsdaten vorgehalten. Im Katastrophenfall werden die Geschäftsoperationen dorthin übertragen, während das Disaster Recovery stattfindet.

8.8.2 Disaster Recovery im Rahmen von ILM Der geneigte Leser wird sich fragen, warum ist auch der Disaster Recovery (DR-) oder Katastrophenfall (K-) Fall für ILM so wichtig. Die Anforderungen für Disaster Recovery müssen einen zentralen Bestandteil der IT-Sicherheitsstrategie jedes Unternehmens bilden. Die Geschäftskontinuität muss gesichert werden. Die entsprechenden Strukturen sorgen dafür, dass die betrieblichen Abläufe nicht unterbrochen werden. Mit dem Eintreten des DR-Falls werden zudem die vorgestellten SLA-Anforderungen an den Betrieb nicht aufgehoben. Signifikant  174

BSI, a.a.O.

246

8 Schlüsselfaktor IT-Sicherheit

erschwerend wirkt sich jedoch aus, dass zusätzlich der Stress des kurzfristigen und schnellen Neustarts für die Mitarbeiter des IT-Services in der DR-Site zu bewältigen ist. Die Analyse der Abläufe im Katastrophenfall und der durchgeführten K-FallÜbungen zeigen häufig die folgenden Verfahrensschwierigkeiten, die einen schnellen Anlauf der Produktion verzögern: x Das Fehlen einer Führungsstruktur bei Disaster Recovery (DR-) Vorgaben. x Verwirrung und Zeitverlust durch Mängel bei der Übergabe zwischen den einzelnen Arbeitsschichten. x Keine festgelegte Aufgabenliste, veränderte Aufgabenverteilung von Schicht zu Schicht. x Keine Überwachung und Kontrolle von Veränderungen. x Fehlende Dokumentation. x Eine zu enge Sichtweise auf die Aufgabenstellung. x Daten wurden nur auf Band gesichert, ohne Einsatz von Softwarelösungen für den Schutz von abhängigen Servern und Anwendungen. x Keine automatisierten Verfahren für das Auffinden der Bänder. x Probleme durch Veränderungen an bereits funktionierenden Systemen. x Mangel an qualifizierten Ressourcen bei den Unternehmen. x Mangelnde Führung (unpassende Anweisungen durch das Topmanagement erschwerten die Recovery-Bemühungen und übten zusätzlichen Druck auf das IT-Personal aus). x Kein dediziertes Dokument, das die Umgebung, Inhalte von Backups oder das Netzwerksetup beschreibt. x In vielen Fällen ist kein Online-Datenschutz vorhanden. Auf der Basis der obigen Erfahrungen lassen sich folgende wichtige Anforderungen an die Disaster-Recovery (DR-) Planung ableiten: x x x x x x x x x

Keine Systeme mit „Single Point-of-Failure“ einsetzen. Verteilte Netzwerke bevorzugen. Komplette und regelmäßige Tests aller Backup-Einrichtungen durchführen. Dokumentation der System-Konfigurationen erstellen. Dokumentation der Disaster Recovery (DR-) Prozeduren erstellen. Dokumentation sind genauso penibel wie Daten schützen (ILM-konform). Dokumentation und Tracking der Bänder implementieren. Geschäftskritische Systeme identifizieren und schützen. Alle Softwareoptionen zum Schutz von Servern, Anwendungen und Bandmedien zusätzlich zu den Daten sichern.

Die Entwicklung, der Einsatz und die Wartung von umfassenden Business Recovery (BR-) Plänen verlangen ein hohes Maß an Einsatz und fordern insbesondere die IT sowohl in technologischer Sicht als auch in Sachen Management. Jede potenzielle Lösung verursacht natürlich Kosten für die Implementierung und den Betrieb. Für die Planung einer entsprechenden DR-Site hat sich das folgende Architekturschema als sehr geeignet erwiesen.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

247

8.8.2.1 Disaster Tier 0: „No Disaster Recovery Plan” Die Kennzeichen dieses „Nicht“-Plans sind: x Kein Backup in externe Site (d. h. zweiter Standort oder eigener BackupStandort, bzw. möglicher eigener K-Fall-Produktionsstandort). x Keine Hardware am zweiten Standort. x Keine spezifische Dokumentation für den Produktionsstart und den Betrieb. x Kein Wiederanlaufplan für zweiten Standort. Es gibt somit keine abgespeicherten Daten, keine Dokumentation, keine zusätzlich vorgehaltene Hardware und keinen „Contingency“-Plan bezüglich der Sicherstellung der IT-Services. Die Dauer der Herstellung der IT-Services nach einem Katastrophenfall ist unvorhersagbar. Es kann durchaus möglich sein, dass sich das Unternehmen nach einem Katastrophenfall nicht mehr erholt (siehe Beispiel am Anfang des Kapitels).

8.8.2.2 Disaster Tier 1: „Backup and Data security without a Hot Site” Die Kennzeichen dieses Plans sind: x Backup in externer Site (zweiter Standort oder eigener Backup-Standort; KFall-Produktionsstandort). x Keine Hardware am zweiten Standort. x Wiederherstellung beginnt mit der Hardwarebestellung. x Keine Dokumentation. x Kein Wiederanlaufplan für zweiten Standort. Im Vergleich zur Nichtplanung stehen theoretisch zumindest die Daten zur Verfügung. Ob sie jedoch genutzt werden können, ist nicht sichergestellt. In Abhängigkeit von der Häufigkeit der Datensicherungen sind Stunden, Tage bis zu Wochen an Datenverlust zu akzeptieren. Zusätzlich fehlen in dieser Stufe die Server-, Mainframe- und Speichersysteme auf welchen die Daten wieder herstellbar sind. Damit ist die Dauer der Wiederherstellung der IT-Services nach einem Katastrophenfall unvorhersagbar. Es besteht somit ein erhebliches Risiko, dass ein Unternehmen die wirtschaftlichen Nachwirkungen des Verlustes nicht verkraftet. Aus Datensicht gibt es folgende zwei alternative Lösungsmöglichkeiten: a) Backup-to-Tape auf Bandlaufwerk/Tape-Library mit Speicherung der Tapes an einem sicheren Ort (z. B. in einem Safe in anderem Gebäude) Der einzige Vorteil ist, dass die Daten gesichert werden. Die Nachteile dieser Lösung sind: x Ein täglicher Bänderwechsel ist erforderlich. x Die Bänder müssen täglich an einen sicheren Ort transferiert werden.

248

8 Schlüsselfaktor IT-Sicherheit

x Der Datenverlust beträgt maximal einen Tag. x Im Desasterfall muss zunächst Hardware vor Ort beschafft werden (inklusive Bandlaufwerk). x Der Restore-Vorgang mittels Band ist meist sehr zeitaufwendig. x Zudem ist ein hoher administrativer Aufwand notwendig. x Ein hoher Unsicherheitsfaktor besteht hinsichtlich der Qualität der Bänder. b) Transfer der Daten in der Nacht über das WAN in das Systems Operation Center (SOC) Die Vorteile dieser Lösung sind in der automatisierten Datensicherung (kein menschliches Eingreifen ist erforderlich) und im zentralisierten Backup-to-Tape zu sehen. Zusätzlich kann typische Serverhardware vorrätig gehalten werden, so dass der Datenverlust maximal einen Tag beträgt. Die Nachteile dieser Lösung sind: x Es muss ausreichende Bandbreite für den nächtlichen Transfer der Daten zur Verfügung stehen. x Im Katastrophenfall müssen die Daten entweder über das WAN auf neu beschaffte Hardware vor Ort restauriert werden (Engpass: Bandbreite) oder x Ersatzhardware muss vorkonfiguriert werden.

8.8.2.3 Disaster Tier 2: „Backup and Protection by Hot Site – Server-out-of-Pool” Die Kennzeichen dieses Plans sind: x x x x x

Backup in externer Site (zweiten Standort; K-Fall-Produktionsstandort). Hardware/System am zweiten Standort. Dokumentation am zweiten Standort. Wiederanlaufplan für zweiten Standort vorhanden. Wiederherstellung beginnt mit Hardware Rebuild.

Im Rahmen des Modells werden reguläre Sicherungen auf Band erstellt. Die Ausgestaltung der Sicherung berücksichtigt die spezifischen Anforderungen des K-Fall-Standortes einschließlich der vorgehaltenen Hardware (Hote Site bzw. Standort). Hier werden die Daten von jenen Bändern im Fall einer Katastrophe auf der vorgehaltenen Infrastruktur wieder hergestellt und die IT-Services wieder gestartet. Diese Stufenlösung benötigt Stunden bis Tage bis zur vollständigen Wiederherstellung aller Services. Aus Datensicht gibt es folgende zwei alternative Lösungsmöglichkeiten: a) Backup-to-Tape auf Bandlaufwerk/Tape-Library mit Speicherung der Tapes an einem sicheren Ort (z. B. Safe in anderem Gebäude) Vorteilhaft ist, dass die Daten zumindest gesichert werden und keine neue, zusätzliche Hardware beschafft werden muss. Die Nachteile dieser Lösung sind: x Ein tägliches Bänderwechseln ist erforderlich. x Die Bänder müssen täglich in den zweiten Standort transportiert werden.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

x x x x

249

Der Datenverlust beträgt maximal einen Tag. Der Restoreprozess vom Band ist langsam. Es ist ein hoher administrativer Aufwand notwendig. Die Lösung stellt einen hohen Risikofaktor dar.

b) Transfer der Daten in der Nacht über das WAN in das Systems Operation Center (SOC) Als Vorteile können hier die automatisierte Datensicherung, d. h. die Sicherung ohne menschliches Eingreifen, sowie das zentralisierte Backup-to-Tape angesehen werden. Die Nachteile dieser Lösung sind: x Es muss ausreichende Bandbreite für den nächtlichen Transfer der Daten zur Verfügung stehen. x Im Katastrophenfall müssen die Daten über das WAN restauriert werden; auch hier kann die Bandbreite für den Datentransfer den Engpass darstellen. x Der Datenverlust beträgt im Extremfall maximal einen ganzen Tag. Für das Backup in einer externen Site bestehen dieselben Möglichkeiten wie in Stufe 2. Ein Unterschied könnte darin liegen, dass nicht alle Daten über das WAN übertragen werden, sondern nur solche Daten, die zentralisiert auf Band gesichert werden sollen. Dadurch wird die benötigte Bandbreite im WAN reduziert. Ist Speicherkapazität an einem zweiten Standort vorhanden, so können die Daten mittels SnapMirror/SnapVault auf diese Hardware kopiert werden. Je nach Wichtigkeit der Daten und Geschwindigkeit der Verbindung zum zweiten Standort können die Daten dort synchron (oder semi synchron) gehalten werden oder die Änderungen werden zu definierten Zeitpunkten zum zweiten Standort übertragen (z. B. jede Stunde). Im Desasterfall kann auf dem Speicher in dem zweiten Standort gearbeitet werden (nach entsprechender manueller Konfiguration). Voraussetzung hierfür ist allerdings, dass auch entsprechende Serverhardware am zweiten Standort bereitsteht. Nach dem Ende des Katastrophenfalls kann der Speicher im ersten Standort mit den Daten des zweiten Standorts rekonstruiert bzw. wieder aktualisiert werden. Die Vorteile der Lösung sind: x Automatisierte und damit aus Sicht der Qualitätssicherung sichere Datensicherung. x Geringer Datenverlust (maximal der Umfang der gewählten Übertragungsfenster; d. h. zum Beispiel eine Stunde). x Relativ kurze Wiederanlaufzeit (maximal im Stundenbereich) und damit nur eine kurzfristige Produktionsunterbrechung. Die Nachteile dieser Lösung sind: x Speicher und Server müssen am zweiten Standort vorrätig gehalten werden. x Eine ausreichende Bandbreite im WAN muss zwischen den beiden Standorten verfügbar sein.

250

8 Schlüsselfaktor IT-Sicherheit

8.8.2.4 Disaster Tier 3: „Backup and Data protection based on Hot Site  Server displacement” Die Kennzeichen dieses Plans sind: x x x x x x

Backup in externer Site (zweiter Standort; K-Fall-Produktionsstandort). Hardware/System am zweiten Standort. Dokumentation am zweiten Standort. Wiederanlaufplan für zweiten Standort. Verfahren um statische Daten zu restoren. Wiederherstellung beginnt mit Operating System (OS-) Rebuild oder OSReboot.

DR-Modell Tier 3 setzt auf Bestandteile von Tier 2 auf. Zusätzlich werden hier befehlskritische Daten übertragen. Modell Tier 3 reduziert den Datenverlust nach einer Katastrophe merklich. Im Gegensatz zur Speicherlösung von Tier 2 sind die Server in der Lösung Tier 3 bereits mit den statischen Daten vorkonfiguriert. Aus Datensicht gibt es zwei alternative Lösungsmöglichkeiten: a) Backup-to-Tape auf Bandlaufwerk oder Tape-Library mit Speicherung der Tapes an einem sicheren Ort (z. B. in einem Safe in einem anderen Gebäude) Die Vorteile sind: x Die Daten werden gesichert. x Es muss keine neue Hardware beschafft werden. Die Nachteile dieser Lösung sind: x x x x

Ein täglicher Bänderwechsel ist erforderlich. Die Bänder müssen täglich in den zweiten Standort transportiert werden. Der Datenverlust beträgt maximal einem Tag. Der Restore-Vorgang vom Band ist langsam, fällt aber im Katastrophenfall nicht an, da es bereits erfolgt ist. x Es entsteht ein hoher administrativer Aufwand. b) Transfer der Daten in der Nacht über das WAN Die Vorteile sind: x Automatisierte Datensicherung (kein menschliches Eingreifen erforderlich). x Zentralisiertes Backup-to-Tape ist möglich. Die Nachteile dieser Lösung sind: x Ausreichende Bandbreite für den nächtlichen Transfer der Daten muss zur Verfügung stehen. x Im Katastrophenfall müssen die Daten über das WAN restauriert werden (Engpass kann hier die erforderliche Bandbreite des Netzwerkes sein). x Ein Datenverlust von maximal einem Tag ist möglich.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

251

8.8.2.5 Disaster Tier 4: „Point-in-time Copies – Server exclusive/shared” Die Kennzeichen des Tier-4-Modells sind: x x x x x x

Backup in externer Site (zweiter Standort; K-Fall-Produktionsstandort). Hardware/System am zweiten Standort. Kopie der Daten auf Disk. Dokumentation am zweiten Standort. Wiederanlaufplan für zweiten Standort vorhanden. Wiederherstellung beginnt mit Daten-Rebuild und Applikations-Rebuild.

Das Tier-4-Modell erlaubt eine schnellere Wiederherstellung des IT-Services nach einem Katastrophenfall, wobei diese Lösung einen größeren Bedarf an Plattenkapazität hat. Die typische Wiederherstellzeit beträgt Stunden, wobei auch hier der Verlust von Daten noch möglich ist. In der praktischen Umsetzung ist es für die Administratoren einfacher und sicherer, die notwendigen Sicherungen „Point-in-Time“ (PIT) und/oder durch Kopien mit größerer Häufigkeit anzufertigen im Vergleich zu einer Tape-basierten Lösung und dieses Backup dann auch für die Wiederherstellung zu nutzen. Zusätzlich im Vergleich zu den Lösungsmodellen Tier 2 und 3 steht am zweiten Standort ein zweites Speichersystem mit dem benötigten Plattenvolumen zur Verfügung. Hier können zusätzlich besonders wichtige Daten oder solche Daten, die auf Bänder gesichert werden müssen, transferiert werden, so dass u. a. eine geringere Bandbreite benötigt wird. Auf das zweite Speichersystem werden die Daten mittels SnapVault übertragen. Dadurch ist am zweiten Standort der komplette Datenbestand vorhanden. Die Übertragung erfolgt allerdings nicht synchron, sondern asynchron. Die sich ergebenden Vorteile dieses Lösungskonzeptes sind: x Automatisierte Datensicherung (es ist kein menschliches Eingreifen erforderlich). x Kurze Wiederanlaufzeit (maximal 1 Stunde) ist realisierbar. Die Nachteile dieser Lösung sind: x Maximal ist 1 Stunde Datenverlust möglich (bei entsprechender Bandbreite zwischen den beiden Standorten). x Manuelles Eingreifen zum Aktivieren des Speichers am zweiten Standort ist notwendig.

8.8.2.6 Disaster Tier 5: „Transaction Integrity – Server exclusive or shared” Die Kennzeichen dieses Modells sind: x x x x

Backup in externer Site (zweiter Standort; K-Fall-Produktionsstandort). Hardware und System am zweiten Standort. Dokumentation am zweiten Standort. Wiederanlaufplan für zweiten Standort vorhanden.

252

8 Schlüsselfaktor IT-Sicherheit

x Konsistente Daten zwischen beiden Standorten (two phase commit). x Wiederherstellung durch Daten Ready, Run, Sessionumschaltung. Das Tier-5-Modell ist immer dann gesetzt, wenn der maximale Umfang eines Datenverlustes (data loss) minimiert werden muss. Die typische Widerherstellzeit bewegt sich im Bereich von Minuten, wobei der Datenverlust auf die letzte nicht abgeschlossene Transaktion begrenzt bleibt. Zusätzlich zum Tier-4-Modell wird hier darauf geachtet, dass die Datenbanken sich zum Zeitpunkt des Snapshots, d. h. der Aktualisierung der Kopie im zweiten Standort, in einem konsistenten Zustand befinden. Dies wird dadurch erreicht, dass die Datenbanken in den Hot-Backup-Modus versetzt werden. Dies geschieht entweder durch den Einsatz spezieller Software (z. B. SnapManager für SQL-Server) oder durch kurze Skripte. Ein Tier-5-Lösung ist in seinen Möglichkeiten Tier 4 auf jeden Fall vorzuziehen, wenn insbesondere ein sicherer Wiederanlauf von Datenbanken gewährleistet werden muss. Der Vorteil des Tier-5-Modells liegt insbesondere darin, dass die Datenkonsistenz weitestgehend sicher ist. Der Nachteil besteht darin, dass spezielle Software oder Skripte für einen sicheren Wiederanlauf notwendig sind.

8.8.2.7 Disaster Tier 6: „Zero or little data loss – Server exclusive or shared” Die Kennzeichen dieses Modell sind: x x x x

Backup in externer Site (zweiter Standort; K-Fall-Produktionsstandort). Hardware/System am zweiten Standort. Keine Abhängigkeit von Anwendungen (z. B. Cluster). Wiederherstellung durch „Redo Logs“ (evtl. plus asynchrone oder synchrone Daten), Aktivsetzen der Standby Datenbank und Applikationsstart. x Logische Datenbestände. Insbesondere das Tier-6-Modell ist geeignet für IT-Services, die nur eine extrem kleine Toleranz bzw. keine Toleranz bezüglich „data loss“ haben und bei denen die Aufrechterhaltung des IT-Service für die Geschäftsprozesse eine zwingend Geschäftsgrundlage ist, wie dies bei Trader-Systemen insbesondere während der Geschäftszeiten der Fall ist. Die typische „logische Wiederherstellzeit“ liegt im einstelligen Minutenbereich mit geringem oder ohne Datenverlust. Die letzten Daten der Anwendungen werden dabei zügig wiederhergestellt. Das Lösungsmodell Tier 6 hat keine Abhängigkeit von den Anwendungen, und sorgt so für die Datumsbeständigkeit. Im Unterschied zu Tier 5 werden hier die „Redo Logs“ mit (semi-) synchronem SnapMirror (anstelle von SnapVault) auf den zweiten Standort übertragen. Die Vorteile des Tier-6-Lösungsmodells sind: x Die Datenbanken sind in einem konsistenten Zustand und können mittels der Redo-Logs auf einen aktuellen Stand gebracht werden. x Der Datenverlust ist auf den Transaktionsbereich begrenzt, d. h. die noch nicht abgeschlossenen Transaktionen.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

253

Neben den zusätzlichen Kosten besteht ein zweiter Nachteil des Tier-6Modells darin, dass die benötigte Bandbreite für die synchrone Datenübertragung für ein semi-synchrones Schreiben sehr hoch ist.

8.8.2.8 Disaster Tier 7: „High automated, business-integrierte Solution – Server exklusiv or shared” Die Kennzeichen der Tier-7-Lösung sind: x x x x x

Backup in externer Site (zweiter Standort; K-Fall-Produktionsstandort). Hardware und System am zweiten Standort. Automation für vollständige Site-Übernahmen. Wiederherstellung im Katastrophenfall gemäß Tier-6-Modell. Logische Datenbestände.

Die Tier-7-Lösung nutzt alle größeren Bestandteile der Tier-6-Lösung einschließlich der zusätzlichen Integration der Automatisierung. Dies erlaubt der Tier-7-Lösung die Beständigkeit von Daten in einem Höchstmaß zu sichern, auch im Vergleich zur Sicherung in der Tier-6-Lösung. Die typischen Wiederherstellzeiten können weniger als eine Minute betragen. Im Vergleich zu Tier 6 wird hier insbesondere der Wiederanlauf der Anwendungen automatisiert. Die Tier7-Lösung erlaubt damit eine viel schnellere und zuverlässigere Restaurierung von Systemen und Anwendungen, als dies bei manuellen Verfahren möglich wäre. Am zweiten Standort steht ein zweites Speichersystem, das alle Datenbestände synchron enthält und im Katastrophenfall automatisch die Daten liefern kann. Die Synchronität der Daten wird durch „Remote Mirroring“ sichergestellt. Die Überwachung der Funktionalität der Speichersysteme und eine automatische Aktivierung des zweiten Standorts werden durch „Mirroring Software“ der Hersteller durchgeführt. Das Backup-to-Disk erfolgt zusätzlich, damit Langzeitsicherungen auf Bänder nicht die produktiven Systeme belasten und weil die Kosten des Speicherplatzes auf SATA-Speicherplatten deutlich niedriger sind. Der zusätzliche Vorteil besteht darin, dass kein Datenverlust stattfindet und zudem ein automatisches Umschalten der Applikationen im Katastrophenfall erfolgt, sodass der Nutzer faktisch keine Unterbrechung seiner Arbeit erfährt. Als Nachteile der Lösung sind anzusehen: x Hohe Anforderungen an die Bandbreite zwischen den beiden Standorten (sonst langsame Schreibvorgänge). x Hohe Kosten für die notwendige Hardwareredundanz. x Backup-to-Disk ist zusätzlich erforderlich, um die Tagessicherungen zu erhalten. Die zusätzliche Automatisierung des Wiederherstellungsprozesses („Restoration“) der Systeme und Applikationen erlaubt eine deutlich schnellere und insbesondere sichere Wiederherstellung und damit eine kürzest mögliche Produktions-unterbrechung.

254

8 Schlüsselfaktor IT-Sicherheit

8.8.2.9 Disaster Tier 8: „Twin location automated, business integrated Solution” Zu den wichtigsten Erkenntnissen aus der WTC-Katastrophe gehört die Aufwertung der Bedeutung des Online-Datenschutzes (siehe Beispiel am Anfang des Kapitels). Er ist besonders wichtig, um den Geschäftsbetrieb in dem Zeitraum aufrechtzuerhalten, der für die Wiederherstellung nach einem Katastrophenfall benötigt wird. Dem Online-Datenschutz kommt daher eine Schlüsselfunktion zu, die überwacht werden muss, um einen unterbrechungsfreien Betrieb sicherzustellen. Dies ist annähernd ebenso wichtig wie die Band-Backups selbst. Automations-Tools, die eine konstante Überwachung sicherstellen und jederzeit kohärente und verwendbare Daten liefern, sind dabei entscheidend. Vor dem Hintergrund dieser Erfahrung waren die beiden Autoren bei der Planung, den Tests und den ersten Umsetzungen einer über zwei Standorte verteilten Produktion gemäß dem Modell „Disaster Tier 8“ beteiligt. Die Kennzeichen der Tier-8-Lösung sind: x Verteilte Produktion über zwei Standorte. x In jedem Standort ist mindestens die Infrastruktur aufgebaut, die für die Erfüllung der Minimal-SLA erforderlich ist, falls ein Standort teilweise oder ganz ausfällt. x Backup vice versa in der jeweils zweiten Site. x Betrieb der Server im Cluster oder als „virtueller“ Server. x Automation des vollständigen Schwenks. x Garantierte logische Datenbestände. x Kostenreduktion, da keine Infrastruktur für einen K-Fall vorgehalten wird, sondern immer auch produktiv genutzt wird. Das Ziel einer deutlich verbesserten Wertschöpfung, auch aus einem Disaster Recovery (DR-) System, liegt auf der Hand. Wenn man ohnehin einen komplett ausgestatteten zweiten Standort für den Notfall unterhalten muss, warum sollte man ihn die restliche Zeit nicht für die Produktion nutzen. Dass dieser Gedanke nicht neu ist, das belegen die folgenden Zitate: Carte r von Fujitsu: „Für einen Kunden stellt schon die Einrichtung eines Datenzentrums ein kostspieliges Unterfangen dar, ganz zu schweigen von zweien.“175 Fernando von Veritas: „Die Zeiten sind vorbei, als Disaster Recovery bedeutete, dass als Absicherung gegen Ausfälle alles doppelt vorhanden sein musste.“176 Morrisey von XSI: „Statt teure Produktionsumgebungen und -ausstattungen an entfernten Standorten zu replizieren, gibt es heute kostengünstigere technologische Lösungen, wobei die Disaster-Recovery-Ausstattung nun für Schulungen, Entwicklung oder Erprobungen zur Verfügung steht.“177  175 176 177

Fujitsu Siemens, Pressemitteilung. Veritas, Pressemitteilung. XSI, Pressemitteilung.

8.8 Disaster Recovery als Teil einer IT-Sicherheitsstrategie

255

Clive Gold, Director of Integrated Marketing bei EMC: „Wir sprechen hier von produktiven Sicherungsmaßnahmen. Ein zweiter Standort kann für zahlreiche Zwecke eingesetzt werden, statt nur im Dunkeln zu verstauben. Es erweist sich meist am nützlichsten, wenn an beiden Standorten exakte Kopien betrieben werden.“178 Penny von Dell: „In den vergangenen sechs Monaten haben noch weitere interessante Entwicklungen stattgefunden. Die Speichersysteme arbeiten nun mit einer Kombination aus Fibre-Channel-Strukturen für die Performance und IDE-Platten für umfangreichere, langsamere Speicherungen. Dies hat den Markt grundlegend verändert. Früher war diese Vorgehensweise sehr teuer, doch heute sind die Preise gesunken. Die meisten Unternehmen arbeiten zwar mit Bandspeichern, da diese weniger kosten, doch sind IDEPlatten nicht mehr viel teurer als die Bänder.“179 Ein wichtiger Faktor für diese Entwicklung waren die Fähigkeit der Speichersysteme, auch über größere Distanzen die Daten absolut synchron zu spiegeln, und die Verbesserungen der Backup-Technologien, sowohl im Hinblick auf die Software als auch auf die Hardware. Im Hardwarebereich bestand der wichtigste Fortschritt im verstärkten Einsatz von Plattenspeichern anstelle von Bändern für die Backups. Aktuell ist auch unter wirtschaftlichen Gesichtspunkten eine verteilte Produktion an zwei Standorten mit einer räumlichen Distanz in der Größenordnung 100 km sicher möglich. Eigene Tests der Autoren im Rahmen des Twin-Core-Rechenzentrum- Projektes der T-Systems bestätigen dies. Die gemessenen Latenzzeiten bedingt durch die Totzeiten der Systeme der Netzinfrastruktur und die notwendige Lichtlaufzeit für die Überbrückung der Entfernung ergaben Zeiten in der Größenordnung 4 ms. Wenn man dies mit den Latenzzeiten von schlecht konfigurierten Speichersystemen von bis zu 100 ms vergleicht, so können die heutigen bereits realisierten Beispiele klar bestätigten, dass der verteilte Betrieb über zwei Standorte keine merkliche Performance-Beeinträchtigung verursacht. Die Tier-8-Architektur hat ein großes Leistungspotential für anspruchsvolle Aufgaben in Konzernen und macht den Weg frei für eine unternehmensweite mehrstufige System- und Speicherarchitektur. Bei der Konzeption wurde das Hauptaugenmerk auf die einzelnen Funktionsbausteine des Speicher, des Archiv- und des Content-Systems als eigenständige Einheit gerichtet, die im Zusammenwirken eine leistungsfähige Gesamtarchitektur ergeben. Der verteilte Betrieb der Serverkomponenten auf eigenständigen Hardwareeinheiten ermöglicht zudem die hohe Skalierbarkeit des Gesamtsystems. Die Tier-8-Architektur erlaubt den Einsatz unterschiedlicher Applikations- und Micro-Server zur Prozessautomatisierung. Eigene Client-Applikationen können sehr einfach über http/Soap oder Citrix angebunden werden. Der Archivserver speichert alle Dokumentenformate und lässt sich für die Archivierung großer Datenmengen mit  178 179

2,

EMC Pressemitteilung. Dell, Pressemitteilung.

256

8 Schlüsselfaktor IT-Sicherheit

HSM-, NAS- oder SAN-Systemen sowie dedizierten Langzeitspeichern wie Jukeboxen oder EMC-Centera ausstatten. Für die Anbindung bestehender BusinessApplikationen gibt es eine Vielzahl an Integrationsmöglichkeiten (z. B. DokImporter auf XML-Basis) sowie Links und Serverbausteine (beispielsweise Contentserver für SAP, ArchiveLink für Lotus Notes). Ein synchroner Betrieb von Servern als Cluster und „virtuelle“ Server sorgt dafür, dass die Architektur auch bei großer Last und Aufgabenvielfalt nicht außer Tritt kommt. Notwendig ist eine spezifische DR-Lösung für die eingesetzten „virtuellen“ Server. Problematisch bei der Umsetzung der vorgeschlagenen Tier-8-Architektur ist jedoch meist die mangelnde Interoperabilität der eingesetzten SANInfrastruktur.

8.8.3 Aktuelle Entwicklung: Interoperabilität im SAN Die vom Supported Solutions Forum (SSF) der Storage Networking Industry Association (SNIA) ausgehende Initiative verfolgt vor allem zwei Ziele: die Datenspiegelung zwischen räumlich verteilten Speichernetzwerken zu ermöglichen und isolierte SANs zu einer Fabric zu verbinden. Im Rahmen dieser Initiative wurden umfangreiche Interoperabilitätstests von zwei gemeinsam entwickelten offenen SAN-Lösungen für die Verlängerung von Speichernetzwerken sowie mehrere Möglichkeiten für Disaster Recovery und Backup durchgeführt. Mit ihren Lösungen wollen die Unternehmen (Inrange, Hitachi Data Systems (HDS), IBM, EMC, StorageTek sowie Veritas Software) gezielt auf die steigende Nachfrage von Anwendern nach skalierbaren, interoperablen Systemen für heterogene Umgebungen reagieren. Unter dem Label „Supported Solution“ sind Lösungen zusammengefasst, die ihre Interoperabilität unter Beweis gestellt haben und Anwendern größtmögliche Unterstützung und Investitionsschutz rund um Aufbau und Betrieb von Speichernetzwerken offerieren. Von dem offenen SAN-Solution-Set, das nun von der Herstellerinitiative angeboten wird, können sich insbesondere jene Unternehmen Vorteile versprechen, die zum Beispiel an einem Rund-um-dieUhr-Betrieb interessiert sind und im Bedarfsfall auf ein Notfallrechenzentrum oder den zweiten Standort umschalten können müssen, oder ihre Datenbanken zum Schutz vor Ausfällen spiegeln wollen. Ebenso interessant ist das Angebot für Anwender, die ein hochverfügbares, skalierbares SAN betreiben und dem Speichernetz nach Bedarf weitere Ports hinzufügen wollen, ohne den Betrieb oder die Leistung zu beeinträchtigen. Angesprochen sind Unternehmen, die den Einsatz beziehungsweise die Konsolidierung von Bandspeichersystemen favorisieren, einzelne SANs in einer einzigen Fabric zusammenfassen wollen, ihre Speichersysteme durch Lösungen unabhängiger Anbieter für Path Failover und Load Balancing ergänzen wollen oder LAN-free Backup/Recovery in Verbindung mit einem Disaster Recovery (DR-) Konzept implementieren wollen. Um dieses Anforderungsspektrum überzeugend adressieren zu können, enthält das offene „SAN Solution Set“ zahlreiche technologische Highlights. Beispielsweise bringt Inrange ihre „Channel Extension“-Technologie ein, mit der

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

257

zwei verteilte SAN-Inseln zu einer SAN-Fabric zusammengeführt werden können. IBM und HDS ihrerseits liefern Server, die ebenso in der gleichen Datenzone eingesetzt werden können wie die Bandspeicher von IBM und StorageTek. Ferner sorgen Managementlösungen von Legato und Tivoli für Backup und Restore von Plattenspeicher auf und von Bandlaufwerken, während Vertias eine Lösung beisteuert, die komplettes Path Failover, dynamisches Multi-Pathing sowie Load Balancing ermöglicht. Abgerundet wird das Leistungspaket von unter AIX, Sun und Windows laufenden Serversystemen, die Zugang zu allen Speicherelementen offerieren und sowohl Platten- als auch Bandspeichersysteme adressieren, sowie von der Datenspiegelung von DB2- und Oracle-Datenbanken zur Sicherung der Datenverfügbarkeit und für Backup und Recovery von IT-Anwendungen. In der Praxis rücken, wie beschrieben, Disaster Recovery und Business Continuity in den ILM-Modellen zunehmend in den Blickpunkt. Besonderes Augenmerk richten die Hersteller daher auf den sicheren Betrieb von Speichernetzwerken. Herausragende Bedeutung kommt dabei der synchronen Datenspiegelung zu, da erst sie eine zuverlässige und kostengünstige Strategie darstellt, um Daten zeitgleich an zwei Standorten vorzuhalten und so den unmittelbaren Zugriff erlaubt und damit entscheidend die Datenintegrität von Speichernetzwerken absichert. Mit ihrer Initiative unterstreichen die Hersteller ihre Absicht, im Rahmen von hochverfügbaren Speichernetzwerken die Unternehmen bei einer zentralen, zukunftssichernden Aufgabe zu unterstützen.

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie 8.9.1 Anforderungen Die folgenden beiden Beispiele sollen die Bedeutung der Archivierung insbesondere im Rahmen von ILM verdeutlichen: x Ein Global agierendes Finanzinstitut ist schon heute verpflichtet, rund um seine Business-Prozesse und Archive mehr als 720 Bestimmung einzuhalten. Die IT-Verantwortlichen müssen dafür Sorge tragen, dass die Dokumente eines Unternehmens über deren gesamten Lebenszyklus verwaltet, lesbar gehalten und betreut werden. Im Unterschied zu früher liegen die Dokumente nicht mehr in staubigen Archiven, Kellern, Containern oder Lagerhallen. Papier spielt keine Rolle mehr, denn die neuen Datenträger heißen CD, DVD, Festplatte oder Bandspeicher. x Der Mainframe einer Versicherung produziert täglich zehntausende Anschreiben, Verträge, Kontoauszüge oder Rechnungen. Früher druckten die Unternehmen diese Informationen auf Papier oder speicherten sie auf Microfiche. Heute leiten sie den Druckstrom direkt in die digitalen Archive. Damit veränderten sich auch die Werkzeuge der Archivare. Locher, Aktenordner

258

8 Schlüsselfaktor IT-Sicherheit

oder Umlaufmappen sind heute nur noch die Synonyme vergangener Konzepte, die im digitalen Zeitalter nicht mehr wirtschaftlich darstellbar sind. Heute heißen die notwendigen Tools Scanner, Records-Management, Enterprise-Content-Management oder Konverter. Der Prozess der Archivierung setzt zudem immer früher ein und endet immer später. Der Verantwortliche ist ab der Erstellung der digitalen Dokumente und für deren Management während des gesamten Lebenszyklus zuständig. Er ist dafür verantwortlich, die verschiedenen Datenströme aus den Applikationen abzufangen, die Archive im Unternehmen zu konsolidieren und sämtliche Geschäftsprozesse nachvollziehbar zu dokumentieren. Er ist für die Vernichtung der Daten zuständig und übernimmt auch die Verpflichtung, die Kunden seines Unternehmens über die Löschung der sie betreffenden Daten zu unterrichten.

8.9.2 Compliance Unter Compliance versteht man, dass die IT, hier die Archivierung, allen gesetzlichen Auflagen entspricht und auch allen aus Gesetzen abgeleiteten Regelungen, z. B. der Finanzbehörden, Rechnung trägt. Dies ist bei der Umsetzung der beschriebenen Maßnahmen sichergestellt, gleichwohl sind die archivierten Informationen aus IT-Sicherheitssicht: x vor unbefugtem Zugang schützen, x die genutzten Verfahren und Prozesse dokumentieren, x die Aufbewahrungsfristen dokumentieren und einhalten.

8.9.2.1 Schutz vor unbefugtem Zugang Unternehmen, bei denen mehr als vier Mitarbeiter mit der Erhebung, der Verarbeitung oder Nutzung personenbezogener Daten beschäftigt sind, müssen einen Datenschutzbeauftragten stellen. Dies kann ein Mitarbeiter oder ein externer Dienstleister sein. Der eigene IT-Verantwortliche scheidet wegen des bestehenden Interessenkonflikts in der Regel aus.

8.9.2.2 Verfahren und Prozesse dokumentieren Hier ist gemäß dem vorgestellten internationalen Standard ISO 20000 eine Prozessbeschreibung anzufertigen, in dem die Verantwortlichkeiten definiert und die Verfahrensanweisungen schriftlich fixiert sind.

8.9.2.3 Aufbewahrungsfristen dokumentieren und einhalten Die Aufbewahrungsfristen sind gemäß den vorgestellten einschlägigen Vorgaben für jede Dokumentart eindeutig zu definieren und den vorgestellten ILMKonzepten entsprechend zu hinterlegen.

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

259

8.9.3 Geeignete Aufstellung von Archivsystemen „Da in Archivsystemen wichtige Daten konzentriert aufbewahrt werden, müssen deren IT-Komponenten so aufgestellt werden, dass nur Berechtigte Zutritt haben. Dies betrifft neben den eingesetzten Servern und Netzkomponenten insbesondere die Speichereinheiten (Plattenarrays, Bandlaufwerke, Disc-Jukeboxen). Für die geeignete Aufstellung dieser IT-Komponenten sind alle relevanten Maßnahmen, die in Baustein 4 des IT-Grundschutzhandbuchs zur Infrastruktur-Sicherheit beschrieben sind, zu realisieren. Je nach Art und Größe des Archivsystems sind die Bausteine B 2.1 Gebäude, B 2.9 Rechenzentrum, B 2.4 Serverraum bzw. B 2.7 Schutzschränke heranzuziehen. Hierbei sollte besonders auf eine ausreichende Zuverlässigkeit der infrastrukturellen Komponenten (Stromzufuhr etc.) geachtet werden.“ 180 Häufig werden elektronische Archive so realisiert, dass Archivmedien im dauerhaften Zugriff durch die Speichereinheit gehalten werden. Hierzu kommen vielfach dedizierte Speichereinheiten zum Einsatz, die selbsttätig Wechselmedien verwalten und einlegen können, beispielsweise Roboter für Bandlaufwerke oder Jukeboxen für Disc-Medien. Wenn ein Archivsystem solche Komponenten beinhaltet, werden in der Regel die Archivmedien während ihrer gesamten Lebensdauer nicht mehr aus der Speichereinheit ausgelagert. Das bedeutet, dass die an Archivmedien zu stellenden Lagerbedingungen (bezüglich Klimatisierung, Zugriffsschutz etc.) bereits in der Speicherkomponente erfüllt und überwacht werden müssen. Bei Auswahl des Archivsystems ist daher als Kriterium zu berücksichtigen, dass die erforderlichen Lagerbedingungen für Archivmedien in Speicherkomponenten eingehalten werden können bzw. welcher Zusatzaufwand hierfür entsteht.

8.9.4 Geeignete Lagerung von Archivmedien „Für den Langzeiteinsatz von Archivmedien sind besonders der Zugriffsschutz sowie klimatische Lagerbedingungen zu beachten und deren Einhaltung zu überwachen. Sofern Archivmedien im Online-Zugriff, also im Archivsystem bzw. in Speicherlaufwerken, gehalten werden, ist keine räumliche Trennung zwischen Archivsystem und Archivmedium realisierbar. Für die geeignete Lagerung von Archivmedien sind damit die in „M 1.59 Geeignete Aufstellung von Archivsystemen genannten Empfehlungen“ umzusetzen.“ 181 Wenn Archivmedien außerhalb des Archivsystems „offline“ gelagert werden, so sind die vom BSI im Baustein B 2.5 Datenträgerarchiv beschriebenen Maßnahmen unter besonderer Berücksichtigung der Anforderungen an die Klimatisierung anzuwenden. Die klimatischen Anforderungen an die Haltbarkeit von Archivmedien hängen insbesondere von den eingesetzten Archivmedien ab. Die einzelnen Hersteller geben hierzu unverbindliche Hinweise bezüglich der Lager 180 181

BSI, a.a.O. BSI, a.a.O.

260

8 Schlüsselfaktor IT-Sicherheit

bedingungen (z. B. Temperatur und Luftfeuchte) und zur Haltbarkeit der Medien an. Für den langfristigen Einsatz elektronischer Archivsysteme müssen die konkreten Lagerbedingungen von den Herstellern der eingesetzten Archivmedien verbindlich erfragt werden. Da die Haltbarkeit der Archivmedien von der konstanten Einhaltung der Lagerbedingungen über den gesamten Einsatzzeitraum abhängt, muss insbesondere dieser Punkt vor der Auswahl der verwendeten Archivmedien geklärt werden. Die Lagerbedingungen müssen daher im Betriebshandbuch des Archivsystems dokumentiert werden. Zusätzlich muss sichergestellt werden, dass die Lagerbedingungen kontinuierlich eingehalten und überwacht werden. Physikalische Schutzmaßnahmen über die klimatischen Bedingungen hinaus müssen die verwendeten Archivmedien vor unautorisiertem Zugriff und mechanischer Beschädigung oder Veränderung schützen. Hierbei sind insbesondere die vom BSI im Baustein B 2.5 Datenträgerarchiv genannten Maßnahmen umzusetzen. Neben einer Kontrolle des Zutritts zum Datenträgerraum, Brandschutz und Schutz vor Wassereinwirkung sind je nach Art der verwendeten Archivmedien weitere Maßnahmen zu realisieren, wie z. B. der Schutz vor Einwirkung von Magnetfeldern auf die beschriebenen Magnetbänder. Auch hierzu sind die verbindliche Festlegungen der Hersteller bezüglich der mechanischen Lagerbedingungen einzuholen und zu beachten. Bei Nichteinhaltung der Lagerbedingungen über den gesamten Einsatzzeitraum muss eine Alarmierung und eine definierte Reaktion erfolgen. Hierzu sind im Rahmen eines IT-Sicherheitskonzeptes die notwendigen organisationsspezifischen Eskalationsprozeduren und -wege zu definieren.

8.9.5 Rechtliche Anforderungen an die Archivierung Die Abbildung von Geschäftsprozessen und -unterlagen in elektronische Dokumente erfordert eine geeignete Ablage der entstehenden Daten für die spätere Verwendung, deren Wiederauffindung und Aufbereitung. Dies betrifft sowohl Datensätze als auch die elektronischen Repräsentationen papierner Geschäftsdokumente und Belege. Die dauerhafte und unveränderbare Speicherung von elektronischen Dokumenten und anderen Daten wird als Archivierung bezeichnet. Nicht allein, dass steuerrelevante Dateien ggf. 10 Jahre und länger in revisionssicherer Form archiviert werden müssen. Hinzu kommt, dass die Geschäftsführung für die Sicherheit der betriebswichtigen Daten und Systeme persönlich haften kann. Eine geordnete, jederzeit verfügbare Aufbewahrung der elektronischen Geschäftspost ist aber auch aus Gründen der strategischen Rechtssicherheit unabdingbar, insbesondere um das Unternehmen für eine etwaige juristische Auseinandersetzung beweisrechtlich zu positionieren. Indessen greift die uneingeschränkte Archivierung der gesamten Kommunikation ohne geeignete betriebliche Regelungen schnell in die Rechte der Mitarbeiter ein. In diesem Spannungsfeld diametral gegenläufiger Interessen und Rechtspflichten geht der Überblick allzu leicht verloren. Das hat nicht selten die fatale Folge, dass Unternehmensführung und Belegschaft ohne erkennbare Organisation der elektronischen Geschäftsabläufe aus reiner Unkenntnis „vor sich hin wursteln“. Die

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

261

Sanktionen für Verstöße gegen archivierungsrelevante Buchführungs- und Datenschutzpflichten sind erheblich. Speziellere Gesetze und Richtlinien für die Datensicherung ergeben sich aus dem Handelsgesetzbuch und der Abgabenordnung in Verbindung mit den Grundsätzen ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS von 1995) und den Grundsätzen zum Datenzugriff und zur Prüfbarkeit originär digitaler Unterlagen (GDPdU von 2002), die von allen Buchungspflichtigen zu beachten sind. Die genannten Rechtspflichten betreffen somit die sichere Informationsverbreitung und Informationsaufbewahrung. Stets geht es um sensible Information in Datenform und ihre Verfügbarkeit in bestimmter Form für eine bestimmte Dauer, kurz – und um abermals im Jargon zu bleiben – um ILM. Gehaftet wird hier unter anderem für die technisch und rechtlich sichere Aufbewahrung und die jederzeitige Integrität und Verfügbarkeit solcher Daten. Die Haftungsfolge tritt ein bei Fehlen oder Ungeeignetheit eines auf ihren Schutz, notfalls auf ihre Wiederherstellung gerichteten Konzepts. Die im Rahmen der IT-Sicherheit geforderte Datensicherung betrifft insbesondere auch Lotus Notes. Deren Rechtsnatur kann vielfältig sein.

8.9.6 Lotus Notes und E-Mail als rechtsrelevante elektronische Erklärungen Zum einen kann es sich um elektronische Erklärungen handeln, weshalb es im Geschäftsverkehr erforderlich ist, täglich seine Accounts zu überprüfen. Denn bereits der Zugang, d. h. die Abrufbarkeit vom Mailserver, kann aufseiten des unternehmerisch tätigen Empfängers (bzw. seiner Mitarbeiter) Rechtsfolgen auslösen, ohne dass es der tatsächlichen Kenntnisnahme vom Inhalt der Lotus Notes bedarf. Vorsicht ist daher geboten bei der Verwendung von Mailadressen auf Visitenkarten, im Internet oder auf Geschäftsbriefen. Geht etwa eine elektronische Rechnung oder Mahnung zu, werden hierdurch bereits Zahlungs- bzw. Verzugsfolgen ausgelöst. Und im Handelsverkehr zwischen Kaufleuten gilt, dass der Vertragspartner auf ein ihm unterbreitetes Angebot unverzüglich mit einem so genannten kaufmännischen Bestätigungsschreiben reagieren, also ggf. widersprechen muss. Tut er dies nicht, muss er sich an dem vom Vertragspartner bestätigten Vertragsinhalt festhalten lassen, auch wenn er von ganz anderen Abmachungen ausgegangen war. Sein Schweigen gilt hier kraft Handelsbrauchs als Zustimmung. Wer also bei seinem geschäftlichen Auftritt eine Erreichbarkeit über seine geschäftliche Mailadresse suggeriert, muss auch für die tägliche Kontrolle dieser Mailbox sorgen.

8.9.7 Lotus Notes und E-Mail als Beweismittel bei der Dokumentation betriebswichtiger Vorgänge Über die vertragliche Komponente hinaus ist die Lotus Notes und E-Mail zum anderen auch Gegenstand notwendiger (oder zumindest kaufmännisch gebote-

262

8 Schlüsselfaktor IT-Sicherheit

ner) Dokumentation. Gerade das Beispiel Lotus Notes und E-Mail zeigt besonders deutlich das Interesse des Unternehmens, zu seiner eigenen Rechtssicherheit und beweisrechtlichen Positionierung so viele Informationen wie möglich zu sammeln, abzuspeichern, auszuwerten und für die Zukunft verfügbar zu halten. Dies beinhaltet häufig den Wunsch, bis zur Auslastungsgrenze der Speicherkapazität sämtliche Geschäftskorrespondenz automatisiert zu erfassen und über einen längeren Zeitraum zu sichern. Denn in einem Prozess muss jede Partei die ihr günstigen Tatsachen darlegen und beweisen. Und wenngleich die Lotus Notes im Grundsatz keinen höheren Beweiswert hat als beispielsweise ein Ausdruck aus dem Internet, die Kopie eines Papierdokuments oder die Vorlage einer Fotografie (etwas anderes gilt nur für Lotus Notes, die mit einer qualifizierten elektronischen Signatur nach Signaturgesetz versehen sind) und daher als Gegenstand der freien Beweiswürdigung nur dem Augenschein des Gerichts unterliegt, bietet sie jedoch in der Regel einen beweisrechtlichen „Wettbewerbsvorteil“. Denn der Ausdruck einer Lotus Notes ist häufig das einzige Beweismittel, das dem Gericht zu seiner Entscheidungsfindung vorliegt. Sie schafft mithin Indizien für den Aussteller, den Empfänger, das Absendeund Zugangsdatum und die Richtigkeit des in ihr niedergelegten Inhalts. Darüber hinaus kann sie eine wertvolle Gedächtnishilfe für die Zeugenvernehmung bilden. Die jeweils andere Partei, die sich gegen den mit der Lotus Notes begründeten Sachverhalt wehren will, ist wegen ihrer prozessualen Wahrheitspflicht daran gehindert, die in der Lotus Notes dokumentierten Angaben pauschal zu bestreiten. Einwände, die Mail stamme nicht vom Aussteller, sei beim Empfänger nicht zugegangen, enthalte falsche Datumsangaben oder sei inhaltlich verfälscht worden, wären daher von der dies einwendenden Partei genauestens zu substantiieren.

8.9.8 Grenzen der Dokumentation: Lotus Notes & E-Mail versus Mitarbeiterschutz Die Maximalschwelle solcher Vorsorge bildet hier, wie eingangs angedeutet, jedoch das Datenschutzrecht und das Fernmeldegeheimnis der Mitarbeiter. So gilt bei erlaubter oder geduldeter Privatmail im Grundsatz, dass ohne die Zustimmung der Mitarbeiter oder ihrer Vertretung (Betriebsrat/Personalrat) eine Überwachung der Inhalte der Kommunikation unzulässig ist. Wichtig ist ferner, dass private Mail dem Mitarbeiter gehört und von ihm herausverlangt werden kann, dies prinzipiell auch nach seinem Ausscheiden. Auch ist es problematisch, Privatmail durch Spamfilter zu unterdrücken oder gar zu löschen. Zur Überwindung dieser Interessenkonflikte sind rechtlich-organisatorische Maßnahmen letztlich unabdingbar. Gemeint sind individualvertragliche Vereinbarungen zwischen Arbeitgeber und Arbeitnehmer in Form von Betriebsvereinbarungen, IT-Sicherheitund User-Policies sowie fortwährende Schulungs- und Qualifizierungsmaßnahmen der Belegschaft.

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

263

8.9.9 Lotus Notes und E-Mail als Gegenstand der gesetzlich zwingenden Dokumentation von Geschäftsvorfällen Wenig verbreitet ist die Erkenntnis, dass Unternehmen nach handelsrechtlichen und steuerrechtlichen Grundsätzen verpflichtet sind, ihre Geschäftskorrespondenz („Handels- oder Geschäftsbriefe“) aufzubewahren. Dies betrifft Unterlagen, die für die Übersicht über einen bestimmten Geschäftsvorfall (im Sinne von Vorbereitung, Durchführung, Rückgängigmachung) bedeutsam sein können, gleichgültig in welcher Form (Briefe, Telefaxe, Lotus Notes) diese vorliegen. Gemeint sind also bspw. Aufträge und deren Bestätigung, Lieferpapiere, Rechnungen und Rechnungskopien, Reklamationen samt dazugehöriger Stellungnahmen, Gutschriften und Zahlungsbelege, Kontoauszüge, Bescheide über Steuern oder Gebühren, Kassenunterlagen, Produkt- und Preislisten (inkl. entsprechender Rundmailings zur Kundeninformation), Verträge, Gehaltsunterlagen etc. Hintergrund dieser weit reichenden Verpflichtung sind die Erfordernisse der Transparenz und Revisionssicherheit, d. h. die Archivierung aller Belege und Dokumente, die für eine betriebliche Überprüfung von Bedeutung sind, aber auch vor Gerichten eine Bedeutung erlangen können.

8.9.10 Zulässige Archivierungsformen Nach den Bestimmungen des Handels- und Steuerrechts können die empfangenen und abgesandten Geschäfts- und Handelsbriefe und die Buchungsbelege auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsgemäßer DV-gestüzter Buchführungsysteme (GoBS) entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten mit den empfangenen Handelsbriefen und den Buchungsbelegen bildlich und mit den anderen Unterlagen inhaltlich übereinstimmen, wenn sie lesbar gemacht werden, x dass sie während der Dauer der Aufbewahrungsfrist verfügbar sind und x dass sie jederzeit innerhalb angemessener Frist lesbar gemacht und für die Besteuerung maschinell ausgewertet werden können. Handels- und Steuerrecht verlangen vom Unternehmer mithin Transparenz sowie Revisions- und Datensicherheit. Die GoB bilden dabei den Regelungsrahmen für die handelsrechtlichen Grundsätze der Ordnung, Nachvollziehbarkeit und Fälschungssicherheit, während die im Zuge der Abgabenordnungsänderung entstandenen GDPdU diese Grundsätze letztlich auf alle originär hergestellten digitalen Unterlagen von steuerrechtlicher Relevanz erstrecken. Neben geeigneten Sicherheitsvorkehrungen gegen die unberechtigte Kenntnisnahme, Unauffindbarkeit, Vernichtung und den Diebstahl von gesicherten Programmen und Datenbeständen stellen GoBS und GDPdU insbesondere Vorschriften für die Archivierung digitaler Dokumente und für den Zugriff auf diese Dokumente im Rahmen von Betriebsprüfungen auf. Dabei muss die Prüfbarkeit und Belegbarkeit sämtlicher Geschäftsvorfälle gewährleistet sein, die Nachvoll-

264

8 Schlüsselfaktor IT-Sicherheit

ziehbarkeit etwaiger Stornierungen und Änderungen, die Datensicherheit, die interne Kontrolle und die Einhaltung der gesetzeskonformen Aufbewahrungsfristen. Notwendig ist ferner eine umfassende Verfahrensdokumentation dieser Abläufe, die nachvollziehbar beschreibt, wie die relevanten Informationen angelegt, geordnet, gespeichert, indiziert und geschützt wurden und später wieder gefunden und verlustfrei reproduziert werden können. Die archivierten Daten müssen in wiedergabefähiger, maschinell lesbarer und auswertbarer Form zur Verfügung gestellt werden können. Ihre periodengerechte Auswertung durch die jeweils aktuelle Prüfsoftware der Finanzverwaltung muss gewährleistet sein. Der Steuerpflichtige ist insoweit zur Kooperation verpflichtet. Bei der Archivierung von Lotus Notes ist außerdem darauf zu achten, dass auch die Anhänge (Attachment) und – im Falle der Signierung und Verschlüsselung – auch die verschlüsselten und entschlüsselten Dokumente nebst Schlüsseln mit aufbewahrt werden. Betroffen sind zum einen alle steuerrelevanten Unterlagen, also sämtliche Informationen, die für eine steuerliche Veranlagung im Sinne von Entstehen, Entfallen oder Minderung einer Steuerlast eine Bedeutung erlangen können. Andererseits geht es bei den Aufbewahrungspflichten freilich – wie bereits dargestellt – nicht allein um die im engeren Sinne steuerrelevanten Unterlagen. Gemeint sind darüber hinaus die gemäß Handelsrecht aufbewahrungspflichtige „bloße“ Geschäftskorrespondenz und die einschlägigen Organisationsunterlagen des Unternehmens (z. B. Gründungsprotokolle, Prüfberichte, Aufsichtsratsbeschlüsse, ferner aber auch die Arbeitsverträge, Lohn- und Sozialversicherungsunterlagen der Arbeitnehmer oder die im laufenden Geschäftsbetrieb abgeschlossenen Verträge mit der in diesem Zusammenhang angefallenen Korrespondenz, gleichgültig in welcher Form).

8.9.11 Folgen einer Verletzung der Archivierungspflicht Werden jedoch, wie in der Praxis häufig anzutreffen, die Ordner und Mailboxen in regelmäßigen Abständen „auf eigene Faust“ analysiert, Altbestände in Archivordner verschoben und Mails, die für überholt (und daher nicht mehr geschäftsrelevant) gehalten werden, gelöscht, steht dies häufig im Gegensatz zu den oben genannten Vorschriften. Verstöße werden mit Zwangsmaßnahmen, Schätzung, straf- und bußgeldrechtlicher Ahndung und der Versagung gesetzlicher Steuervergünstigungen sanktioniert.

8.9.12 Archivierungsprozess Die für das Unternehmen entwickelte Speicherlösung mit großen kostengünstigen Speicherkapazitäten schafft neue Möglichkeiten in der Archivierung und vor allem in der Auswertung von Archivdaten. Gleichzeitig findet eine Annäherung der Datenhaltungssysteme (Produktivdaten) und Datenarchivierungssysteme (Langzeit-Archivdaten) statt. Diese Entwicklung eröffnet neue Möglichkeiten bei der Definition von Archivierungsprozessen, welche durch die neuen

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

265

gesetzlichen Rahmenbedingungen grundsätzlich unterstützt werden. Die Archivierungsprozesse müssen in einem größeren Kontext gesehen werden. Außer einer reinen Umstellung der Archivierung vom bewährten Papierarchiv zu elektronischen Archiven besteht noch bedeutend mehr Optimierungspotenzial. Ein moderner und effizienter Archivierungsprozess beginnt bereits bei der Erfassung der Daten und nicht erst mit der Notwendigkeit, Daten aus Systemen zu räumen, wenn die Speicherkapazitäten an ihre Grenzen gelangen. Die erfassten Daten werden zuerst im Produktivsystem genutzt und anschließend elektronisch ins Datenarchivierungssystem überführt. Die hohen technischen und organisatorischen Anforderungen für die Archivierung mittels elektronischer Informationsträger zielen auf eine hohe Fälschungssicherheit und Integrität der gespeicherten Informationen ab. Beim unveränderbaren Informationsträger müssten diese Eigenschaften bereits durch das Produkt selbst erfüllt sein. Artikel 3, 4 und 9 der Geschäftsbücherverordnung (GeBüV) verlangen, dass gewisse Fälschungsrisiken mittels angemessener unternehmensspezifischer organisatorischer Maßnahmen zu minimieren sind (z. B. Prozessmanagement, Protokollierung). Beim Einsatz veränderbarer Informationsträger für die Archivierung ist die Integrität der gespeicherten Informationen von Gesetzes wegen auch mittels technischer Verfahren zu gewährleisten. Als geeignete Maßnahme werden in der GeBüV die digitalen Signaturverfahren genannt. Die Herausforderung bei den digitalen Signaturverfahren liegt jedoch in der Verhältnismäßigkeit der dazu erforderlichen Aufwendungen. So ist es kaum praktikabel, z. B. bei einem Transaktionssystem, jede einzelne Transaktion digital zu signieren. Verzichtet ein Unternehmen auf die (nur beispielhaft genannten) elektronischen Signaturverfahren, sind andere angemessene technische Verfahren zu evaluieren und anzuwenden. Der Zeitpunkt der Speicherung der Informationen auf veränderbaren Informationsträgern muss unverfälschbar nachweisbar sein. Als geeignetes Verfahren nennt der Verordnungsgeber den Zeitstempel. In der Praxis sind die digitalen Zeitstempelungsverfahren allerdings vielfach an die Uhr des Betriebssystems gekoppelt, deren Einstellung relativ einfach änderbar ist. Es sind daher zusätzliche Kontrollen und Maßnahmen erforderlich. Das Unternehmen muss im Rahmen des Klassifizierungsprozesses festhalten, welches sein Verständnis bezüglich der organisatorischen und technischen Anforderungen für die Archivierung ist. Dazu muss zum Beispiel bestimmt werden, x welche Geschäftsunterlagen aufbewahrt werden sollen/müssen (Form, Gründe, Dauer), x welche Speichersysteme und Speichermedien zum Einsatz kommen, x welches die Anforderungen an die Sicherheit und Lösungsansätze bezüglich Unverfälschbarkeit sind, x wie die Prozesse bezüglich Archivierung und Zugriff aussehen und in die operativen Geschäftsprozesse integriert werden sollen, x welche Kontrollen vorhanden sein müssen, um einen sicheren und vertraulichen Archivierungsprozess zu gewährleisten.

266

8 Schlüsselfaktor IT-Sicherheit

Das noch aufzustellende Archivierungskonzept umfasst folgende Komponenten: x x x x x x x x x x x

Systemarchitektur, Gebäudekonzept, Prozess je Dokumentenart, Achivierungsform, Aufbewahrungsdauer, Technische Varianten, Organisation, Betriebskonzept, Sicherheitskonzept, Notfallplan, Pflichtenheft.

8.9.13 Archivierungsformate und Archivierungsformatanforderungen Eine wichtige Anforderung an Archivierungsformate ist die Plattformneutralität, d. h., die Daten müssen auf allen Computersystemen verwendbar sein. Ebenso wichtig ist Herstellerunabhängigkeit, d. h., dass das Format nicht an Hard- oder Software eines einzigen Herstellers gekoppelt ist. Idealerweise handelt es sich um ein freies Format, dessen vollständige Dokumentation öffentlich zugänglich ist und das keinerlei lizenzrechtlichen Beschränkungen unterliegt. Auf das Format soll mit beliebigen Programmiersprachen zugegriffen werden können. Doch auch Daten, die auf allen Plattformen lesbar, öffentlich dokumentiert und lizenzrechtlich frei sind, lassen sich damit noch nicht notwendigerweise sinnvoll recherchieren oder in sinnvoller Weise in verschiedenen Medien ausgeben. Eine einfache Textdatei beispielsweise wird häufig den Anspruch der Systemunabhängigkeit erfüllen. Aber sie kann nur per einfacher Volltextsuche durchsucht und nur durch aufwendige manuelle Arbeit formatiert werden, da schon einfachste Gliederungselemente wie z. B. Überschriften nicht als solche in den Daten gekennzeichnet sind und damit nicht automatisiert verarbeitet werden können. Man kann also noch einen weiteren Anspruch an die Daten hinzufügen, nämlich die Möglichkeit, diese gemäß ihren spezifischen Inhalten und Strukturen automatisch auszuwerten. Es gibt mithin mehrere Gründe, in medienneutralen Daten nicht die Formatierung eines Dokumentes, sondern die Struktur und die Art des Inhalts eindeutig zu beschreiben. Der Wichtigste ist sicherlich, dass die Struktur eines Dokumentes mit seinem Inhalt verbunden ist, während die Formatierung nichts Absolutes ist. Ein Dokument bestimmten Inhalts kann auf unterschiedlichste Weise formatiert werden, ohne dadurch seine Struktur zu verlieren. Wenn also der Text und seine formale wie inhaltliche Struktur eindeutig codiert sind, wird sich jede systematische Formatierung seiner Elemente daraus herstellen lassen. Die Struktur eines Textes in einer objektivierten und für den Rechner lesbaren Form im Dokument abzuspeichern, löst eine ganze Reihe Probleme. Zu-

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

267

nächst wird der Text automatisiert weiterverarbeitbar, und zwar in beliebiger Typografie und für die unterschiedlichsten Ausgabeformen. Damit wird dem Anspruch auf Medienneutralität Rechnung getragen. Da die Struktur explizit in den Daten codiert ist, sind die Daten durch Suchanfragen erschließbar, die die Struktur mit berücksichtigen und so viel genauer formuliert werden können. Schließlich lassen sich in einem Text sehr viel mehr Informationen abspeichern, als zur rein typografischen Umsetzung benötigt werden, z. B. Verwaltungsinformationen.

8.9.14 Langzeitstabile Formate für textbasierte Informationen: SGML, HTML und XML 8.9.14.1 SGML Der Ursprung des ersten Standards lag im Bestreben der Publisher im Industrieund Verlagsbereich, ein Standarddatenformat für Textinhalte zu schaffen, das der Verwendung in verschiedenen Publikationssystemen (Print, elektronische Publikationen) ebenso entgegenkommt wie der Auswertbarkeit durch Rechnersysteme (z. B. für intelligente Suchanfragen). Solche Daten nennt man „medienneutral“. Medienneutrale Daten müssen in einer Form vorgehalten werden, die für alle gewünschten Publikationsformen als Quelldatenformat dienen kann. Ein erster medienneutraler Standard wurde 1986 mit der Standard Generalized Markup Language (SGML) geschaffen. SGML ist eine Auszeichnungssprache, die als internationaler Standard alle textuell wiedergebbaren Inhalte strukturieren kann. Eine SGML-Datei stellt eine ganz normale Textdatei dar, die sich auf allen Plattformen und mit einfachster Software öffnen lässt. Die Auszeichnung oder Markierung (engl. Markup) der Inhalte mit weitergehenden Informationen erfolgt ebenfalls in Textform, wobei die Auszeichnungen mit Begrenzungszeichen (engl. Delimiter) von den Inhalten abgegrenzt werden. Auszeichnungen in SGML können auch ganze Abschnitte umfassen, die z. B. als „Kapitel“ oder „Abschnitt“ markiert sind, wobei Abschnitte auch in Unterabschnitte geschachtelt auftreten können. Jeder Abschnitt kann wiederum seine eigene Überschrift tragen. Auszeichnungen in SGML können so gestaltet werden, dass sie selbsterklärend und auch ohne Software verständlich sind. Eine so gestaltete SGML-Datei kann auch als Papierausdruck gelesen und verstanden werden. SGML-Software kann die Auszeichnungen verwenden, um den markierten Text z. B. in einem bestimmten Layout anzuzeigen oder spezifisch nach Textstellen in Überschriften zu suchen. SGML ist dabei nicht selbst eine Auszeichnungssprache (d. h., es werden keine bestimmten Auszeichnungen vorgegeben), sondern es definiert die Syntax, in der eigene Auszeichnungssprachen definiert werden können. Jede Art von Dokument soll entsprechend seiner Eigenart nach Inhalt und Struktur erschlossen werden können. SGML löst dieses Problem dadurch, dass keine Struktur und keine Elemente vorgegeben werden, sondern eine Sprache zur präzisen Beschreibung von

268

8 Schlüsselfaktor IT-Sicherheit

Dokumentstrukturen bereitgestellt wird. So kann der Anwender selbst festlegen, welche Textelemente mit welchen Tags ausgezeichnet werden sollen. Diese Möglichkeiten werden von Anwendergruppen (Industriezweige, Verlagsverbünde) genutzt, die für ihre Inhalte passende Auszeichnungen definieren, um diese Inhalte leichter austauschen und automatisiert verarbeiten zu können. Allerdings hat SGML einen Vorteil, der ihm in der Praxis zum Nachteil gereicht, nämlich seine extreme Flexibilität und Komplexität. SGML lässt dem Nutzer so viele Möglichkeiten und bietet so komplexe Konstruktionen an, dass es sehr aufwendig ist, Software zu programmieren, die den Standard voll umsetzt. Daher hat sich SGML nur begrenzt durchsetzen können. Anwendung findet SGML insbesondere dort, wo große Datenmengen codiert werden müssen und die finanziellen Ressourcen nicht zu knapp sind.

8.9.14.2 HTML SGML fand über alle Nutzergruppen hinweg weltweite Verbreitung als Hypertext Markup Language (HTML), die Seitenbeschreibungssprache für InternetBrowser, festgelegt vom World Wide Web Consortium (W3C), dem InternetStandardisierungsgremium. HTML ist also eine konkrete Anwendung von SGML – allerdings eine extrem beschränkte. Wenige festgelegte Auszeichnungen dienen dem einzigen Zweck, Text und Grafiken im Web-Browser zu formatieren bzw. zu positionieren und Webseiten mit Links zu verbinden. Mit HTML können medienneutrale oder inhaltlich orientierte Auszeichnungen nur sehr begrenzt vorgenommen werden. Diese Grenzen von HTML, die auch dem Datenaustausch im Internet zunehmend hinderlich wurden, führten dazu, dass das W3C 1998 mit der eXtensible Markup Language (XML) eine neue Auszeichnungssprache definierte.

8.9.14.3 XML XML ist wie SGML keine Sprache mit einem festen Repertoire von Auszeichnungen, sondern eine Sprache zur präzisen Beschreibung von Dokumentstrukturen mittels frei festlegbarer Auszeichnungen. Sie ist also im Gegensatz zum ganz und gar vordefinierten HTML erweiterbar (extensible). Andererseits sind bei XML viele Merkmale, die bei SGML frei bestimmbar waren, konkret festgelegt. Während die ISO-SGML-Norm über 500 Seiten umfasst, kommt die Druckfassung des XML-Standards mit 26 Seiten aus. Durch die Vereinfachung der Programmierung von Anwendungssoftware entstand eine breite und kostengünstige Basis für die praktische Nutzung. Diese Basis hat zusammen mit der vergleichsweise einfachen Anwendbarkeit der Sprache XML zu ihrer enormen Verbreitung beigetragen. XML hat SGML de facto verdrängt, nur in wenigen Fällen wird SGML noch verwendet. Der Vorteil der Verbreitung von XML wiegt die Einschränkungen gegenüber SGML leicht auf. Inzwischen arbeiten fast alle relevanten Anwendungen im Publishing-Bereich mit XML, angefangen mit Microsoft Office über Satzprogramme bis hin zu On-

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

269

line-Publishing-Systemen. Aber XML ist nicht immer gleich XML – das XML, das in Microsoft Word verwendet wird, enthält wie schon HTML vorrangig Formatierungsinformationen, während die medienneutrale Verwendung Informationen über Inhalt und Struktur benötigt. Dennoch ist die XML-Fähigkeit der meisten Programme eine Voraussetzung für die breite Nutzung des Formats. Um beim Beispiel Microsoft Office zu bleiben – mit PlugIns kann man Microsoft Word nun auch dazu bringen, als Editor für inhalts- und strukturorientiertes XML zu dienen. Für die medienunabhängige Codierung von Textinhalten eignet sich XML in ausgezeichneter Weise. Es erfüllt dabei zugleich alle Kriterien, die an ein langzeitstabiles Datenformat gestellt werden können.

8.9.15 Langzeitstabile Formate für Pixelgrafiken: TIFF Tagged Image File Format (TIFF) ist ein Datenformat zur Speicherung von Bilddaten. Es wurde ursprünglich von Aldus (1994 von Adobe übernommen) und Microsoft für gescannte Bitmapbilder entwickelt. Es ist eines der wichtigsten Formate zum Austausch von Daten in der Druckvorstufe. Die Dokumentation ist frei verfügbar. ISO-normiert sind die TIFF-Spezifikationen für Digitalfotografie (TIFF/EP; ISO 12234-2:2001) und die medienunabhängige Bildverarbeitung (TIFF/IT; ISO 12639:2004). Eine sehr große Verbreitung hat die Basisversion von 1992 (TIFF 6.0). TIFF ist plattformunabhängig. Software zur Erstellung und Verarbeitung von TIFF ist für alle Hard- und Softwareplattformen verfügbar, alle professionellen Grafik- und Satzprogramme akzeptieren TIFF-Dateien. TIFF eignet sich in besonderem Maße für den Druck, da es sowohl Farbmanagementinformationen, Farbseparation und den Beschneidungspfad für Bildmotive ohne Hintergrund speichern kann. Für die Archivierung ist die verlustfreie Qualität des TIFF-Bildes gefragt. TIFF berücksichtigt verschiedene Verfahren zur Datenkomprimierung. In einer TIFF-Datei können mehrere Bilder abgelegt werden. Das können verschiedene Versionen desselben Bildes sein, z. B. ein Vorschaubild (Thumbnail) und das Originalbild oder mehrere Bilder mit jeweils einem Vorschaubild. Dabei unterstützt es sowohl verlustlose als auch verlustbehaftete Kompressionsverfahren. Ein Nachteil des TIFF-Formates ist seine Komplexität, die dazu führt, dass es oft von Programmen mit einer fehlerhaften Implementierung nicht richtig verarbeitet wird. Die Vielfalt möglicher gültiger TIFF-Dateien kann zudem von keinem einzelnen Programm vollständig unterstützt werden. In der Spezifikation des Datenformats ist deswegen mit Baseline-TIFF eine Untermenge gültiger TIFF-Dateien definiert, die jedes TIFF-fähige Programm verarbeiten können sollte. TIFF-Dateien sind auf eine Größe von 4 GB beschränkt. Weiterhin können TIFF-Dateien nicht gestreamt werden, d. h., es muss vor einer Anzeige erst die ganze Datei oder ein erheblicher Teil davon geladen werden. Eine Dokumentation des Formats wird von Adobe kostenlos als PDF-Datei zur Verfügung gestellt.

270

8 Schlüsselfaktor IT-Sicherheit

Die aktuelle Version ist TIFF 6.0 vom 3. Juni 1992. Sie wird ergänzt durch TIFF Technical Notes. Dabei handelt es sich um Erweiterungen, die TIFF einzelne Fähigkeiten hinzufügen, u. a. das Deflate-Verfahren zur verlustlosen Datenkompression. Aufgrund seiner Verbreitung und Plattformneutralität ist TIFF als langzeitstabiles Datenformat geeignet, wobei aber die Baseline-Einschränkungen eingehalten werden sollten. Über die Baseline-Spezifikationen hinausgehen, sind folgende Einschränkungen zu beachten: x Farbbilder sind nicht als „Palette-color images“ (Pseudofarben) zu speichern, obwohl dies von Baseline-TIFF unterstützt wird. x Bilder sind immer und ausnahmslos unter Verwendung der verlustfreien (Fax-) Komprimierung Gruppe 4 (Standard der ehemaligen CCITT, heute ITU) zu speichern, obwohl dies technisch gesehen keine Baseline-Option ist. x Colormetrie-Informationen sollten, wenn es möglich ist, mit gespeichert werden. Für Farb- und Graubilder sollte die verlustfreie LZW-Kompression verwendet werden. Diese Option wird derzeit leider relativ selten unterstützt, weil potenziell Lizenzgebühren für die Software, die dieses Verfahren nutzt, anfallen. Da mit LZW-Kompression eine Reduktion der Datenmenge um bis zu 50 Prozent erreicht werden kann, sollte diese Option für Projekte mit großen Datenmengen dennoch in Erwägung gezogen werden.

8.9.16 Langzeitstabile Formate für Pixelgrafiken: PNG Aufgrund seiner technischen Eigenschaften und seines Status als ISO-Norm (seit 2004) und W3C-Recommandation kommt auch das neue Format PNG (Portable Network Graphics) für die digitale Langzeitarchivierung in Frage. Bisher ist PNG jedoch noch nicht so weit verbreitet wie TIFF oder EPS. Die Tatsache, dass PNG und das von PNG verwendete Kompressionsverfahren im Gegensatz zu TIFF vollständig frei von Lizenzansprüchen ist, spricht für seine Verwendung als Datenformat für Archivierungszwecke. Technisch ist PNG ein plattformübergreifendes Datenformat und enthält einen verlustfreien Komprimierungsalgorithmus. PNG eignet sich sowohl für digitale Master als auch digitale Nutzungsformen. Wie auch GIF kann PNG Pixel aus einer Farbpalette mit bis zu 256 Einträgen verarbeiten. Für die Archivierung interessant ist aber eher die Unterstützung hoher Farbtiefen (16 Bit für Graustufenbilder und bis zu 48 Bit für Farbbilder gegenüber 8 Bit bei Graustufen und 24 Bit bei Farbe im Baseline-TIFF-Format). PNG kann Informationen zu Farbmanagement, Farbseparation und den Beschneidungspfad für Bildmotive ohne Hintergrund speichern (Gamma-Faktor, Alphakanal und K-Wert, ab Version 1.2 können auch ICC-Profile eingebettet werden, LAB-Fähigkeit). Anders als TIFF unterstützt PNG einen linearen und schrittweisen Bildaufbau (bereits bei 20–30 Prozent der übertragenen Bilddaten ist der Bildinhalt erkennbar). Damit ist es als Web-Format verwendbar. PNG ermöglicht das Abspei-

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

271

chern zusätzlicher Information, wie zum Beispiel Autoren- und Urheberhinweise in der Grafikdatei. Beim Einsatz von PNG für Archivzwecke sollte nur die verlustfreie Kompression verwendet, auf Palettenfarben verzichtet und so viele technische Bildinformation wie verfügbar mit gespeichert werden.

8.9.17 Langzeitstabile Formate für Pixelgrafiken: GIF, BMP, JPEG, JPEG 2000 Die weit verbreiteten Grafikformate GIF, BMP und JPEG sind nicht für die Langzeitarchivierung geeignet (Ausnahme: JPEG 2000).

8.9.17.1 GIF Graphics Interchange Format (GIF; Servicemarke der CompuServe Inc.) ist ein Format für die Bildschirmdarstellung von Pixelgrafiken und ermöglicht lediglich die Verwendung von maximal 256 Farben aus einer vorgegebenen Palette. Der spezifische Komprimierungsmechanismus ist zurzeit lizenzrechtlich nicht frei.

8.9.17.2 BMP Bitmap (BMP) ist ein ursprünglich proprietäres Grafikformat von Microsoft Windows, das in verschiedenen Varianten vorliegt. Es ist auf die Bildschirmdarstellung von Pixelgrafiken beschränkt und bietet bei weitem nicht die Möglichkeiten der Prepress-Formate TIFF und PNG. Am weitesten verbreitet ist Version 3 (frühere gibt es nicht). Microsoft hat mit Windows 95 und Windows 98 die neueren Versionen 4 und 5 des BMP-Formates eingeführt, die Alphakanäle und Farbkorrektur ermöglichen und als Containerformat für PNG- und JPEGDateien verwendet werden können. Diese neuen Formate sind jedoch nur sehr selten als eigenständige Dateien anzutreffen und werden kaum von Anwendungen unterstützt; sie finden eher als internes Format in Windows-Programmen Verwendung.

8.9.17.3 JPEG Joint Photographic Experts Group (JPEG) verwendet eine verlustbehaftete Kompression, was ein Ausschlusskriterium für die Anwendung in der Langzeitarchivierung ist.

8.9.17.4 JPEG 2000 JPEG 2000 ist dagegen ein äußerst mächtiges Grafikformat, das auch als ISONorm vorliegt. Bei der Entwicklung von JPEG 2000 wurden ausdrücklich die Kriterien berücksichtigt, die die Langzeitarchivierung an ein Format stellt. Aller-

272

8 Schlüsselfaktor IT-Sicherheit

dings hat JPEG 2000 den Status eines tatsächlichen Standards noch nicht erreicht, seine Verbreitung und Akzeptanz ist noch gering. Sollte sich das ändern, ist JPEG 2000 ein starker Kandidat für die Langzeitarchivierung von Pixelgrafiken.

8.9.18 Langzeitstabile Formate für Vektor- und kombinierte Grafiken: EPS Neben TIFF ist Encapsulated Postscript (EPS; von Adobe Systems) das zweite professionelle Standardformat für Grafiken in der Druckvorstufe. Als Austauschformat ist es seit vielen Jahren etabliert. Der Standard ist vom Hersteller vollständig dokumentiert und nicht lizenzbelastet. EPS ist eine Untermenge von Adobes ebenfalls frei dokumentierter Seitenbeschreibungssprache PostScript und Austauschformat für diese. Viele Grafik- und Layoutprogramme auf allen wichtigen Betriebssystemen unterstützen EPS. EPS dient zur Speicherung von Vektorgrafiken, Rastergrafiken mit Halbtönen, formatiertem Text und ganzen Seitenlayouts einschließlich Schriften. Verfügbare Farbmodi sind RGB, Lab, CMYK, Duplex, indizierte Farben und Graustufen. EPS arbeitet mit Farbtiefen von 1, 4, 8 und 24 Bit/Pixel. Im Gegensatz zu PostScript beschreibt EPS pro Datei immer nur eine Seite. Es sind daher einige PostScript-Befehle, insbesondere druckerspezifische, nicht zulässig. Durch die frei verfügbare Dokumentation, die große Verbreitung und die Systemunabhängigkeit ist EPS ebenso wie TIFF für die Langzeitarchivierung geeignet. Allerdings ist eine korrekte Darstellung und Bearbeitung nur über ein Programm möglich, das die Vektorinformationen in EPS verarbeiten kann, was aber mit allen professionellen Zeichenprogrammen möglich ist. Viele Bildbetrachtungsprogramme können das für die Druckausgabe konzipierte EPS aber nicht darstellen. Daher kann in EPS ein Vorschaubild integriert werden, wobei auch plattformspezifische Formate erlaubt sind, was allerdings dem Ziel der Plattformneutralität zuwiderläuft. Als Format für die schnelle Online-Übertragung ist EPS daher ebenfalls nicht geeignet. EPS enthält anders als TIFF auch keinen integrierten Komprimierungsalgorithmus. EPS hat gegenüber TIFF jedoch den Vorteil, dass enthaltene Vektorgrafiken und Schriften in der Größe skaliert werden können, ohne dass die Genauigkeit leidet. Texte und Grafiken können zudem aus EPS-Daten extrahiert werden. EPS ist daher besonders als Langzeitarchivierungsformat für Vektorgrafiken geeignet, insbesondere wenn diese in Kombination mit Texten auftreten (z. B. Charts, Pläne). Bei der Erstellung von EPS sollte auf die folgenden Punkte geachtet werden: x Alle notwendigen Daten wie z. B. Schriften müssen in die EPS-Datei eingeschlossen (inkludiert) werden. x Auf die Abspeicherung von EPS-Daten in Form von Binärdaten (8-Bit-EPS) sollte verzichtet werden, stattdessen sollten sie als ASCII-EPS (7-Bit-EPS) gespeichert werden. Binäre EPS-Dateien sind zwar kleiner, können aber nicht mit allen Systemen gelesen werden. Auf die Einbindung eines Vorschaubil-

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

273

des sollte verzichtet werden, da hier je nach Plattform unterschiedliche Formate verwendet werden, was zu Problemen auf der jeweils anderen Plattform führen kann. Die Einbindung von Vorschaubildern im EPS-spezifischen, plattformneutralen EPSI-Format wird leider von vielen Programmen nicht unterstützt und führt zudem zu einer deutlichen Vergrößerung des Speicherbedarfs. x Die Bounding-Box (das die Grafik umschließende Rechteck) muss korrekt angegeben werden. DSC-Kommentare sollten weitgehend genutzt werden (DSC, Document Structuring Conventions; Angaben zu technischen Spezifika des EPS). Es sollten keine geräteabhängigen Optionen verwendet werden (z. B. für die Rastereinstellung, Transferfunktionen, Überdruckvorschau, Schwarzaufbau, ICC als Gerätefarben). Da die Erzeugung von EPS-Daten mittels Druckertreibern oft zu Problemen führt, sollten stattdessen die EPS-Speicheroptionen professioneller Grafikprogramme verwendet werden. Bei der Wahl von langzeitstabilen Formaten sollte auch der Aspekt einer möglichst einfachen Nutzbarkeit eine Rolle spielen. Hier schneidet EPS aufgrund des Problems der fehlenden Darstellbarkeit durch Standardviewer nicht gut ab. PDF, das als ebenso mächtiges Format für skalierbare und extrahierbare Schriften und Vektorgrafiken in Frage kommt, kennt keine Viewer-Probleme und kann daher als flexiblere Alternative in Betracht gezogen werden (zu PDF und den damit verbundenen potenziellen Problemen siehe weiter unten).

8.9.19 Langzeitstabile Formate für Vektorgrafiken: SVG Scalable Vektor Graphics (SVG) ist eine auf XML basierende Auszeichnungssprache, die seit 2001 als W3C Recommendation vorliegt (seit 2003 als Version 1.1, 1.2 ist in Arbeit). Mit SVG können skalierbare Vektorgrafiken und Vektoranimationen auf der Grundlage von XML codiert werden. Als internationaler Standard und W3C-Norm kommt SVG auch als Format für die Archivierung von Vektorgrafiken in Frage. Auch Texte und Pixelgrafiken lassen sich einbinden. Die Orientierung von SVG auf die Nutzung im Internet bedeutet allerdings, dass SVG bei weitem nicht so viele Formatierungsmöglichkeiten bietet wie EPS oder PDF. Zudem hat SVG noch lange nicht den Verbreitungsgrad der etablierten Formate, ist aber erkennbar auf dem Vormarsch. Solange es um Speicherung und Archivierung von Vektorgraphiken geht, die bereits als SVG vorliegen, spricht nichts gegen die Archivierung der SVG-Daten. Als Alternative bietet sich auch hier PDF an, das Vektorgrafiken und Schriften ebenfalls in skalierbarer und extrahierbarer Form speichern kann.

8.9.20 Langzeitstabile Formate für Seitenbeschreibung und beliebige Grafiken: PDF Portable Document Format (PDF) ist ein Datenformat zur systemübergreifenden Seitenbeschreibung, das von Adobe Systems entwickelt wurde. Es ist neben

274

8 Schlüsselfaktor IT-Sicherheit

PostScript der internationale De-facto-Standard für die Erzeugung von Druckvorlagen. PDF ist ursprünglich ein proprietäres Datenformat. Es basiert zu großen Teilen auf dem Seitenbeschreibungsformat PostScript, ebenfalls von Adobe Systems. Das Format ist im PDF Reference Manual von Adobe vollständig dokumentiert. Dadurch können durch Drittentwickler beliebige PDF-Werkzeuge bereitgestellt werden.

8.9.20.1 PDF als ISO-Norm Seit 2001 hat die PDF-Variante PDF/X (X für eXchange), die speziell dem Dokumentenaustausch dienen soll, den Status einer ISO-Norm (ISO 15930). PDF/X wurde seitdem beständig weiterentwickelt und liegt inzwischen als Version 3 vor (PDF/X-3; ISO 15930-6:2003). Eine weitere Variante speziell für Zwecke der Langzeitarchivierung (PDF/A) ist das ISO/CD 19005-1 Electronic document file format for long-term preservation – Use-of-PDF 1.4 (PDF/A); Veröffentlich 2006-09-01.

8.9.20.2 PDF als Web-Format Seinen hohen Verbreitungsgrad verdankt PDF vor allem dem Adobe Reader von Adobe, einem kostenlosen PDF-Viewer, der sich auch als PlugIn in InternetBrowser einbinden lässt und für alle Soft- und Hardwareplattformen zur Verfügung steht. Dadurch hat PDF weltweit eine herausragende Bedeutung bei der Publikation von formatierten Print-Inhalten über das Internet erhalten. Eine PDF-Druckvorlage ist immer zugleich für die Web-Publikation verwendbar – lediglich die Dateigröße muss minimiert werden, was bei PDF unproblematisch ist, wenn man Qualitätsverluste etwa bei Pixelgrafiken in Kauf nimmt. Das Anzeigen von Printseiten auf einem PC-Bildschirm ist zwar nicht die optimale Lösung für Online-Publishing-Zwecke, aber kostengünstig und im Falle von PDF in der Darstellungsqualität (vor allem auch bei Ausdrucken) sehr zuverlässig.

8.9.20.3 PDF-Features PDF kann von einer Vielzahl von Layout- und Grafikprogrammen erzeugt werden; Dutzende von Tools ermöglichen die Herstellung von PDF aus den unterschiedlichsten Quellen. PDF-Dateien geben die Dokumente der Ursprungsprogramme einschließlich aller Schriften (auch nichteuropäische), Farben, Grafiken und Vektorgrafiken präzise wieder. Da PDF über effektive Komprimierungsmechanismen verfügt, sind PDF-Dateien meist deutlich kleiner als ihre Quelldateien. PDF-Dateien können beliebig viele Seiten Umfang haben, die maximale Seitengröße beträgt 4 u 4 Meter. Schriften und Vektorgrafiken können ohne Qualitätsverlust bis 6400 Prozent vergrößert werden. So finden auch extrem große Übersichten oder Pläne auf einer PDF-Seite den notwendigen Platz. Über die Textsuche im einzelnen Dokument oder die Volltextrecherche innerhalb einer PDF-Dokumentensammlung lassen sich sehr einfach Fundstellen auffinden.

8.9 Archivierung als Bestanteil einer IT-Sicherheitsstrategie

275

Textpassagen, Tabellen und Bilder aus PDF-Dokumenten können leicht in anderen Anwendungsprogrammen durch Kopieren und Einfügen der jeweiligen Elemente weiterverarbeitet werden. Es ist auch möglich, PDF-Dateien direkt zu bearbeiten, z. B. Texte zu ändern oder Grafiken zu verschieben. PDF ermöglicht die Anlage von Lesezeichen, mit deren Hilfe die Anwendungen hierarchische Inhaltsverzeichnisse zur einfachen Navigation durch große Dokumente erzeugen können; ebenso gibt es die Möglichkeit, Links und Anker in PDF anzulegen. Schließlich lassen sich in PDF auch Ton- und Filmdaten unterbringen sowie Formulare mit Skripting-Funktionen erstellen oder Kommentare „anheften“. Mittels des optionalen Dokumentenschutzes mit 40- oder 128-Bit-Verschlüsselung kann der Ersteller des Dokuments gezielt die Rechtevergabe des betreffenden Dokuments steuern. Er kann z. B. verhindern, dass Benutzer das Dokument abändern, ausdrucken oder Inhalte über die Zwischenablage kopieren können. PDF-Dateien können auch mit digitalen Signaturen „unterschrieben“ werden. PDF kann auch als Format zur verlustfreien Abspeicherung von einzelnen Grafiken verwendet werden, und zwar nicht nur von Pixelgrafiken, sondern wegen der Skalierbarkeit von Vektorgrafiken und Schriften auch als Alternative zu EPS und SVG. In der neuesten Version ermöglicht PDF die logische Strukturierung der abgespeicherten grafischen und Textinhalte auf eine ähnliche Weise, wie dies in XML geschieht, nämlich durch Tags als Tagged PDF. Tagged PDF ermöglicht so eine Erschließung der Inhalte, die über ihre rein grafische Repräsentation hinausgeht. Zum einen kann Tagged PDF dafür verwendet werden, die Inhalte je nach Ausgabegerät (Standardrechner, Handheld, Handy) anders zu formatieren, zum anderen können Inhalte besser durchsucht werden, und schließlich können sich Sehbehinderte Tagged PDF vorlesen lassen. Der letztere Punkt hat enorme Bedeutung, da seit 1998 in den USA gesetzlich vorgeschrieben ist, dass von Bundesbehörden veröffentlichte Inhalte auch für Behinderte voll zugänglich sein müssen (Accessibility Act).

8.9.20.4 PDF-Probleme PDF ist alles in allem eine extrem komplexe Technologie, was dazu führt, dass beim Austausch von PDF-Daten nicht immer bei allen Beteiligten und Ausgabegeräten das erwünschte Ergebnis zustande kommt. Schriften oder hochauflösende Grafiken müssen z. B. nicht zwingend in eine PDF-Datei eingebunden werden, sondern können auch lediglich referenziert werden, so dass die Datei von einem Rechner, auf dem die betreffende Schrift oder Grafik fehlt, nicht richtig dargestellt wird oder es bei der Druckausgabe zu Fehlern kommt.

8.9.20.5 PDF/X Diese Situation hat zu Bemühungen geführt, das PDF-Format wieder so weit einzuschränken, dass es für einen bestimmten Zweck zuverlässig nutzbar ist. Für

276

8 Schlüsselfaktor IT-Sicherheit

die Druckvorstufe ist die ISO-Norm PDF/X (X für eXchange) eine solche Lösung. Neben dem Ausschluss von Ton-, Film- und Skripting-Komponenten sowie der Festlegung, dass alle benötigten Daten Bestandteil der PDF-Datei sein müssen, verlangt PDF/X die Einhaltung von Regeln bei Verarbeitungsanweisungen (Farbprofile, Bemaßung u. ä.). So kann man eine PDF-Datei auf PDF/X-Konformität prüfen und sichergehen, dass jeder andere, der PDF/X-konforme Software verwendet, auch das erwünschte Ergebnis erhält (Blind-Exchange-Fähigkeit).

8.9.20.6 PDF/A PDF/A verfolgt das Ziel, den Aufbau und Inhalt von PDF-Daten so zu spezifizieren, dass sie die Ansprüche der Langzeitarchivierung erfüllen. Die US-amerikanischen Verbände „Association for Suppliers of Printing, Publishing and Converting Technologies (NPES)“ und die „Association for Information and Image Management International (AIIM International)“ arbeiten seit einigen Jahren auf dieses Ziel hin: Sie wollen mit PDF/A einen internationalen Standard für die digitale Archivierung von Schriftgut definieren. Wie schon erwähnt, hat PDF/A auf dem Gebiet der Langzeitarchivierung den Status einer ISO-Norm gemäß ISO 19005: PDF/A erhalten. Archive, Behörden und Verwaltungen sollen ebenso von diesem Standard profitieren wie Gerichte, Bibliotheken, Zeitungsverlage und Industrieunternehmen. PDF/A soll ein mehrseitiges Dokumentenformat definieren, das eine Mischung aus Texten, Bilddaten und Vektorgrafiken enthalten kann. Ebenso sollen die Eigenschaften und Fähigkeiten der Systeme definiert werden, die für das Lesen, Reproduzieren und die Volltextsuche verwendet werden. Ziel ist es sicherzustellen, dass PDF/A-Dateien alle zur Darstellung des Inhalts notwendigen Daten enthalten und dass diese Daten selbst wieder internationalen Standards entsprechen und unabhängig von Ausgabegeräten sind. Das trifft auch auf die Metadatenebene zu. PDF/A soll alle Metadaten enthalten können, die zur Beschreibung und Auswertung des Dokumentes notwendig sind. Dabei soll PDF/A noch konsequenter vorgehen als PDF/X. Eine Empfehlung für PDF als Format zur Langzeitarchivierung kann nur für die ISO-normierten Varianten PDF/X und das noch in Entwicklung befindliche PDF/A gegeben werden. PDF/X hat nicht primär die Langzeitarchivierung, sondern die Kompatibilität von Daten in der Druckvorstufe zum Ziel, die endgültige Form von PDF/A ist noch abzuwarten. Eine Empfehlung für diese PDF-Typen als Formate zur Langzeitarchivierung birgt zudem das Risiko in sich, dass die Einschränkung auf diese Sonderformen nicht hinreichend Beachtung findet.

8.10 Generelle IT-Sicherheitsanforderungen für ILM Die beiden ISO-Standards 17799 und 27000 in Verbindung mit dem BSI-ITGrundschutz, COBIT und den weiteren einschlägigen Standards machen eindringlich deutlich, dass es ohne ein systematisches Management der Informati-

8.10 Generelle IT-Sicherheitsanforderungen für ILM

277

onen und der IT-Sicherheit keinen wirksamen Schutz für die Daten gibt. Mit den beiden vorgestellten ISO-Standards liegt erstmals eine internationale Orientierung vor, die als Basis für eine „Best Practice“ dienen kann und global kommunizierbar ist. Mit den im BSI-IT-Grundschutz definierten Bedrohungen und dem operationalisierten Maßnahmenkatalog in Verbindung mit den spezifischen Festlegungen in CISA und den in ISO 20000 definierten IT-Service-Prozessen steht eine breite Know-how-Basis zur Verfügung, die es gilt, unter Berücksichtigung der empfohlenen spezifischer IT-Sicherheit-Policies der einzelnen Hersteller zu einem gesamthaften IT-Sicherheitskonzept im Rahmen eines ILM-Konzeptes geschickt zu verknüpfen. Erst die Erfüllung der IT-Sicherheitsrequirements im Rahmen eines ILMProjektes erfordert die Schaffung der folgenden Voraussetzungen: x Effizienz und IT-Sicherheit in einer heterogene IT-Landschaft, die in fast jedem der mehr als 190 Länder, in denen ein international agierendes Unternehmen tätig sein kann, ein anderes Computersystem nutzt, ist unmöglich. Die Wartung der unterschiedlichen Produkte verschlingt zudem Unsummen. Und weil jede noch so kleine Änderung Land für Land umgesetzt werden muss, ziehen sich Anpassungen ewig hin. Effizienz, Flexibilität und IT-Sicherheit sind Fehlanzeige. Erst ein homogenes Netzwerk schafft hier die Grundlage. Egal ob in Deutschland oder Japan – alle Mitarbeiter greifen auf das gleiche Portfolio standardisierter Software zu. Ein homogenes Netzwerk in Verbindung mit Konsolidierung schafft die Grundlage für Innovationen. Zum einen stehen mehr Mittel für Investitionen z. B. für ILM bereit, zum anderen lassen sich Neuerungen schnell und ökonomisch einführen. x Verbesserung der Abstimmung von IT und Unternehmensgeschäft in Form des „Strategic Business-IT Alignment Model“ (SAM). Dieses Modell bestimmt das Zusammenspiel zwischen Geschäftsstrategie, -strukturen und -prozesse sowie der IT-Strategie und der Ausgestaltung im Detail innerhalb der zwei Dimensionen: „funktionalen Integration“ und „strategischer Fit“. Eine adäquate Absicherung der unternehmensinternen IT-Infrastruktur muss heute mehr denn je oberste Priorität haben. Nicht nur, um die Geschäftstätigkeit im eigenen Unternehmen zu gewährleisten, sondern auch um die störungsfreie Abwicklung mit Kunden und Dienstleistern im Rahmen von ILM zu garantieren. Ziel ist es, durch organisatorische, personelle, infrastrukturelle und technische Sicherheitsmaßnahmen ein Standardsicherheitsniveau für IT-Systeme aufzubauen, das auch für sensible Bereiche wie ILM weiter ausbaufähig ist.

9 Schlüsselfaktor Qualitätssicherung

9.1 Bedeutung des Qualitätsmanagements Wir, die beiden Autoren, haben in einem gemeinsamen Projekt innerhalb von zweieinhalb Jahren in Summe 82 ältere Speichersysteme durch 9 neue Speichersysteme desselben Herstellers ersetzt und insgesamt mehr als 250 TB Netto-Daten migriert. Jede ungeplante Produktionsunterbrechung hätte pro Tag eine Konventionalstrafe von mehreren Mio. Euro bedeutet und jeder Produktionsdatenverlust einen Umsatzverlust in zweistelliger Millionen-Euro-Höhe verursacht. Trotz verschiedener „Online Microcode Upgrades“, Plattenausfällen während schwieriger Speichersystemoperationen und der üblichen projektimmanenten Stressfaktoren wurde das Projekt ohne jede ungeplante Produktionsunterbrechung und ohne jeden „data loss“ durchgeführt. Wir haben dies erreicht, weil jede noch so kleine Aktion vor deren Durchführung schriftlich in Form einzelner Schritte geplant, detailliert dokumentiert und vom entsprechenden Engineering verifiziert worden war. Es gab keine spontanen Aktivitäten. Das gesamte Migrationsprojekt war sowohl aus technischer als auch aus wirtschaftlicher Sicht ein Gewinn für den Auftraggeber. Während der Laufzeit des Projektes gab es gleichwohl am obigen RZ-Standort mehrere ungeplante Produktionsunterbrechungen, deren Auswirkungen immer dann besonders groß war, wenn die jeweils betroffenen Mitarbeiter nicht auf detaillierte Beschreibungen zurückgreifen konnten, sondern spontan improvisieren mussten, so unsere Beobachtungen. Der zweite Fall beschreibt das Fehlen einer Qualitätssicherung am Beispiel einer Bank. Hier wurde zwar ein Notfallkonzept entwickelt und man zahlt jährlich einen sechsstelligen Euro-Betrag für die Bereitstellung einer CPU im Bedarfsfall, dem so genannten Desaster-Fall. Bisher hat man jedoch darauf verzichtet, die notwendigen Qualitätssicherungsmaßnahmen einschließlich Risikoanalyse durchzuführen. Insbesondere die fehlenden Tests des Wechsels zur Disaster-Recovery-Site (DR-Site) führten dazu, dass man lieber erhebliche Mehrkosten im hohen sechsstelligen Euro-Bereich beim Ausfall des Mainframes für die kurzfristige Instandsetzung in Kauf genommen hat, um so den nicht QS-gesicherten Schwenk zur DR-Site vermeiden zu können. Aus Risikomanagementgründen ist dies zwar eine nachvollziehbare Entscheidung, aus wirtschaftlicher Sicht jedoch ein Fiasko. Das dritte Beispiel stammt von einem Industrieunternehmen. Die Haftung der Hersteller wird auch hier immer weitreichender. Die Hersteller haften nicht

280

9 Schlüsselfaktor Qualitätssicherung

nur für Konstruktionsschwächen, sondern auch für Materialschwächen. In diesem Sinne wurde der Hersteller von Gartengeräten vor dem LG Dortmund zur Zahlung von Schmerzensgeld verurteilt, das mehr als das 1000-Fache des Warenwertes betrug, obwohl das Werkzeug der Norm entsprach (LG Dortmund: 3O 292/03). Es genügt somit nicht nur, Produkte gemäß der Norm zu konstruieren und den Ablauf des eigenen Produktionsprozesses zu dokumentieren, aus Haftungsgründen sind auch die Prozessparameter des gesamten Herstellungsprozesses zu dokumentieren. Die Liste der Beispiele könnte fast beliebig verlängert werden. Das Bewusstsein für Qualitätssicherung, für Risikomanagement und, wie bereits beschrieben, für IT-Sicherheit ist leider meist nicht sehr stark im Bereich der IT entwickelt. Aber durch das immer stärkere Gewicht der IT innerhalb der unternehmenskritischen Geschäftsprozesse und der möglichen Haftungsrisiken trotz der Einhaltung von Normen wächst das Risiko, dass auch Fehler in der Leistungserbringung des Ist-Service erhebliche wirtschaftliche Auswirkungen haben. Ein wichtiger Punkt insbesondere innerhalb jedes ILM-Konzeptes ist deshalb die kontinuierliche Qualitätssicherung (QS) in Verbindung mit einem entsprechenden Qualitäts- und Risikomanagement.

9.2 Qualitätsmanagement Das Qualitätsmanagement (QM) übernimmt hierbei die Aufgabe der Optimierung von Arbeitsabläufen im Rahmen der Geschäftsprozesse unter der Berücksichtigung von materiellen und zeitlichen Kontingenten sowie den Qualitätserhalt im Produktionsprozess sowie bei der Erbringung von Dienstleistungen einschließlich deren Weiterentwicklung. Hierbei sind von Belang etwa die Optimierung von Kommunikationsstrukturen, professionelle Lösungsstrategien, die Erhaltung oder Steigerung der Zufriedenheit von Kunden oder Klienten sowie der Motivation der Belegschaft. Im Vordergrund des Qualitätsmanagements stehen die Standardisierungen bestimmter Handlungs- und Arbeitsprozesse, Normen für Produkte oder Leistungen, Dokumentationen, berufliche Weiterbildung, Ausstattung und Gestaltung von Arbeitsräumen. Qualitätsmanagement beschreibt somit einen systematischen Weg, um sicherzustellen, dass alle Aktivitäten den Anforderungen entsprechen und wie geplant stattfinden. Der Weg, der in einer Organisation geplant wird um die eigenen Operationen zu bewältigen und gleichzeitig die geforderten Qualitätsdienstleistungen abzuliefern, wird im Qualitätsmanagementsystem spezifiziert. Das Qualitätsmanagementsystem definiert die Organisationsstruktur, Verantwortlichkeit, Richtlinien, Verfahren, Prozesse, Standards und Hilfsmittel, die erforderlich sind, damit die definierte Qualität geliefert wird. Auch im Bereich des Qualitätsmanagements gibt es keinen alles umfassenden Ansatz, sondern unterschiedliche Modelle, die im Rahmen eines ILM-Einführungskonzeptes geschickt entsprechend der jeweiligen Projektphase zu kombinieren sind.

9.2 Qualitätsmanagement

281

Abb. 9.1. Das Deming-Modell

9.2.1 Deming-Modell William Edwards Deming wurde bekannt durch seine Managementphilosophie zur Aufbauqualität und zum Aufbau einer konkurrenzfähigen Produktivität.182 Als Teil dieser Philosophie formulierte er 14 Managementprinzipien. Einige dieser Punkte zielen mehr auf das Dienstleistungsmanagement als andere. Für Qualitätserhöhung schlug Deming den Deming-Zyklus oder Kreis vor. Die vier Schlüsselpunkte sind „Plane, Tue, Überprüfe und Handle“, nach denen eine Phase von Konsolidierung den „Kreis davon abhält, den Hügel hinunterzurollen“. Der Zyklus wird von einem Prozess untermauert. Zu Demings Philosophie des Dienstleistungsmanagements gehören 14 Aktivitäten, die u. a. die folgenden Punkte umfassen: x x x x x

Die Barrieren zwischen Abteilungen sind zu beseitigen. Das Management muss ihre Verantwortung lernen und auf Führerschaft setzen. Jede Prozessverbesserung benötigt auch eine Verpflichtung an der Spitze. Gute Führer motivieren, um zu verbessern. Kontinuierliche Verbesserung ist ein zentrales Thema für Dienstleistungsmanager; dies ist auch ein Thema für das Qualitätsmanagement. x Alle Aufgabe sind mit der Betonung auf Teamwork und Verständnis zu verändern. 

182

Deming, Edwards, www.wirtschaftslexikon24.net, http://de.wikipedia.org.

282

9 Schlüsselfaktor Qualitätssicherung

Deming nutzt bei der Bewertung der Umsetzung zur Prüfung das Capability Maturity Modell (CMM) basierend auf COBIT 3. Dabei geht es nicht um die Benotung, sondern um den Grad der Kontrolle über die geprüften Abläufe und Prozesse. COBIT geht jeweils von einem Ideal aus. Je nach Entwicklungs- bzw. Projektstand kann eine tiefe Bewertung durchaus unter Berücksichtigung der Zeit in Ordnung sein. Der Zweck der Bewertung ist die Vergleichbarkeit, Nachvollziehbarkeit und Verbesserung von Prozessen. Eine kritische Bewertung soll dabei die Aufmerksamkeit auf den Handlungsbedarf und das Verbesserungspotenzial richten. Das dem Deming-Modell zugrunde liegende Capability Maturity Model (CMM) wurde auf Initiative des US-Verteidigungsministeriums (DoD) durch das Software Engineering Institute (SEI) an der Carnegie Mellon University Pittsburgh entwickelt. CMM ist ein Prozessmodell, das zur Beurteilung der Qualität des Softwareentwicklungsprozesses bzw. der Reife von Organisationen und der geplanten Maßnahmen zur Verbesserung der Qualität dient. 2003 wurde CMM durch Capability Maturity Model Integration (CMMI) ersetzt, das 6 Abstufungen beinhaltet:183 x Level 0: Nicht existent Erkennbare Prozesse fehlen vollständig. Die Organisation hat noch nicht erkannt, dass Maßnahmen erforderlich sind. x Level 1: Initiiert Die Organisation hat erkannt, dass Maßnahmen getroffen werden müssen. Es fehlen jedoch noch standardisierte Prozesse. Es werden immer noch Ad-hocMaßnahmen von Fall zu Fall ergriffen. x Level 2: Teilweise definiert Die Prozesse sind so weit entwickelt, dass sie von den verschiedenen Mitarbeitern für gleiche Aufgaben in vergleichbarer Weise angewendet werden. Es existiert jedoch noch keine formale Schulung oder Kommunikation bezüglich des standardisierten Vorgehens. Die Verantwortung ist noch jedem Einzelnen überlassen. x Level 3: Definiert Die Prozesse sind standardisiert und dokumentiert und mittels Schulung kommuniziert. Es ist jedoch den einzelnen Personen überlassen, diesen Vorgaben nachzukommen. Abweichungen werden nur mit kleiner Wahrscheinlichkeit entdeckt. x Level 4: Kontrolliert Die Einhaltung der Prozessvorgaben wird kontrolliert und kann gesteuert werden. Korrekturmaßnahmen sind möglich, falls die Prozesse nicht in der geplanten Weise funktionieren. x Level 5: Optimiert Die Prozesse sind so weit verbessert, dass sie bester Praxis entsprechen, basierend auf ständiger Verbesserung. Werkzeuge zu Verbesserung von Qualität und Effizienz werden eingesetzt. Ziel ist die schnelle Anpassung der Organisation an neue Anforderungen.  183

Maturity Model, http://de.wikipedia.org.

9.2 Qualitätsmanagement

283

Abb. 9.2. Die Qualitätstrilogie gemäß dem Juran-Modell

9.2.2 Juran-Modell Joseph Juran wurde mit der Veröffentlichung des Qualitätskontrollen-Handbuchs zu einem anerkannten Vertreter für den Aufbau der Qualitätssicherung. Juran ersann eine wohlbekannte Tabelle, die „Juran-Trilogie“, um die Beziehungen zwischen Qualitätsplanung, Qualitätskontrolle und Qualitätserhöhung auf einer planungsnahen Projektgrundlage zu repräsentieren.184 Ein weiteres Merkmal des Modells ist die Anerkennung der Notwendigkeit, die Manager zu führen. Dies wird durch die Errichtung eines Qualitätsrates innerhalb einer Organisation erreicht, der verantwortlich für den Aufbauprozess ist, die Projekte norminiert, die möglichen Verbesserungen erkennt und dafür die notwendigen Hilfsmittel bereitstellt. Juran preist in dem von ihm entwickelten Qualitätssicherungsmodell vier schrittweise durchzuführende Annäherungen zur Qualitätserhöhung mit folgenden Eckpunkten an: x Start: Die notwendigen Organisationsstrukturen und die Infrastruktur werden geschaffen. x Prüfung: Die Begriffe werden in Pilotprogrammen ausprobiert und die Ergebnisse bewertet. 

184

Juran, Joseph M.: Jurans Quality Handbook, McGraw Hill, ISBN 0-07-034003-X.

284

9 Schlüsselfaktor Qualitätssicherung

x Scale-up: Die Basisbegriffe werden erweitert. x Institutionalisierung: Die Punktqualitätsverbesserungen werden mit dem strategischen Geschäftsplan verbunden. Juran schuf unter anderem den Begriff der Qualitätstrilogie, die aus den Säulen x Qualitätsplanung, x Qualitätskontrolle und x Qualitätsverbesserung besteht.

9.2.3 TQM Das Total Quality Management (TQM) ist in England sehr populär.185 Trotz seines offensichtlichen Erfolgs im Markt steht TQM in der Kritik. Die Kritik an TQM bezieht sich hauptsächlich auf seine begrenzte Definition von Qualität. Crosby definierte vier Eckpunkte, auf denen aus seiner Sicht das Qualitätsmanagement basiert: x x x x

Die Qualität ist konform zur Anforderung. Ziel ist die Erreichung von Qualität und nicht deren Beurteilung. Der Leistungsziel muss „null Defekte“ sein und nicht „das ist nah genug“. Das Maß für Qualität ist der Preis.

In TQM fehlt die Technikausrichtung von Juran und es findet keine Anpassung des Qualitätssystems an eine Richtlinie statt. Die Entsprechung zum TQMKonzept ist in Deutschland das EFQM-Modell für Excellence der European Foundation for Quality Management.

9.2.4 Six Sigma Das Six-Sigma-Modell versucht die Ursachen für Probleme zu analysieren und zu lösen.186 Dabei werden statistische Prozesssteuerungsdaten benutzt, um Prozessschwankungen zu reduzieren (SPC). Ein Prozess, der gemäß Six Sigma verwendet wird, erlaubt z. B. nur 3,40 Defekte pro eine Millionen Teile. Six Sigma hat sich aufgrund von Erfahrungen von Produktionsunternehmen entwickelt und ist deswegen ohne entsprechende Anpassung weder auf menschliche Prozesse noch auf solche Produktionsprozesse anwendbar, die man nicht sofort klar mit Hilfe von statischen Prozessgrößen beschreiben kann. Die Annäherung erfordert geschultes Personal, das fähig ist, zu identifizieren, welche Verbesserungen benötigt werden, und das entsprechend handeln kann. Es enthält zudem keinen sys 185 186

TQM, http//de.wikipedia.org. Six Sigma, http://www.controllingportal.de/Fachinfo/Grundlagen/Six-Sigma.

9.2 Qualitätsmanagement

285

tematischen Ansatz zur Identifizierung von Verbesserungen, noch erleichtert es die Priorisierung. Neuerdings gibt es erste Nutzungen des Six-Sigma-Modells auch im Dienstleistungsgewerbe. Hier wird auf Basis eines guten Dienstleistungsmanagement-Werkzeuges die Verfolgung von Zwischenfällen ermöglicht und auf diese Weise den Six-Sigma-Ansatz zur Prozessverbesserung genutzt.

9.2.5 Internationaler Qualitätsstandard ISO 9000 Ein wichtiger internationaler Standard ist ISO 9000, eine Gruppe von fünf universellen Standards für ein Qualitätssicherungssystem, das rund um die Welt akzeptiert wird. Anfang des Jahrtausends haben die Länder ISO 9000 als den Eckstein ihrer nationalen Standards angenommen. Der umfassendste Standard ist ISO 9001. Er bezieht sich auf Industrien, das Design, die Entwicklung, die Herstellung, die Installation und das Bereitstellen von Erzeugnissen oder Dienstleistungen. Das Dienstleistungsmanagement gemäß ISO 9000 kann mit der Einführung von ITIL auch in Bezug auf Qualitätssicherung unterstützt werden. Dies erfolgt durch den formalen Standard BS 15000 (Spezifikation für Dienstleistungsmanagement). ITIL ist in vielen Ländern der De-facto-Standard und somit der Vorläufer von ISO 20000, einem formalen internationalen Standard.

9.2.6 EFQM „… der Kampf um Qualität ist eine der Voraussetzungen für den Erfolg der Gesellschaften und für unseren kollektiven Erfolg“, so Jacques Delors, Präsident der Europäischen Kommission, während der Unterzeichnung der Absichtserklärung in Brüssel 1988.187 Die europäische Antwort zur Lösung der Herausforderung Qualitätsmanagement, die European Foundation for Quality Management (EFQM) wurde von den Präsidenten der 14 größeren europäischen Unternehmen mit der Billigung der Europäischen Kommission, gegründet. Die gegenwärtige Mitgliedschaft umfasst mehr als 600 Organisationen, von größeren multinationalen Konzernen und wichtigen nationalen Unternehmen bis hin zu Forschungsinstituten an europäischen Universitäten. Das EFQM-Modell hat einen ganzheitlichen, ergebnisorientierten Ansatz und besteht aus 9 Kriterien und 32 Unterkriterien. Im EFQM-Modell liegt der Schwerpunkt auf dem Wert, den der Benutzer der x x x x

Planung, Ausführung, Überprüfung und Realisation

selbst zuweist, wobei alle Geschäftsoperationen möglichst zyklisch zu durchlaufen sind. Eines der von EFQM bereitgestellten Werkzeuge ist der Selbstabschätzungsfragebogen. 

187

EU Pressemitteilung, www.europa.eu, http://dewikipedia.org.

286

9 Schlüsselfaktor Qualitätssicherung

Abb. 9.3. Das EFQM-Modell

Der Selbstabschätzungsprozess ermöglicht der Organisation, die Aufmerksamkeit auf die Gebiete zu lenken, wo Verbesserungen möglich sind. Der Fragebogenprozess gipfelt in geplanten Verbesserungsaktionen, deren Fortschritt überwacht wird. In dieser Abschätzung kann der Fortschritt gegen eine FünfPunkte-Reifeskala überprüft werden. Im EFQM-Modell für Excellence werden die ersten vier Kriterien als „Enablers“ definiert. Eine Verbindung mit dem „Best Practices“ gemäß den in ITIL definierten IT-Serviceprozesse beschreibt eine Prozessdurchführungen, auf deren Basis eine erfolgreiche und qualitätskonforme Leistungserbringung möglich und die den Kriterien eine richtige Betonung zuordnet. Die Schlüsselpunkte des EFQM-Modell werden im folgenden Abschnitt kurz erläutert.

9.2.6.1 Führerschaft x Organisiere für alle eine Startsitzung. x Definiere ein Rollenmodell. x Ermutige und unterstütze das Personal.

9.2.6.2 Personalmanagement x Schaffe ein Bewusstsein für Qualität. x Rekrutiere neues Personal und/oder engagiere Zeitkräfte, um zu verhindern, dass während der Durchführung das Personal überlastet wird.

9.3 Qualitätssicherung im Rahmen des Projektmanagements

x x x x x x x

287

Schule das Personal durch Training und konkrete Praxiserfahrungen. Richte die Pläne nach Richtlinien und Strategie aus. Nimm einen trainierenden Stil im Management an. Richte die Aktivitäten gemäß den gezahlten Gehältern aus. Entwickle Richtlinien und Strategie für die Personalentwicklung. Kommuniziere Anweisungen, Planungen und Werte. Kommuniziere mit den Mitarbeitern gemäß den Kommunikationsplänen.

9.3 Qualitätssicherung im Rahmen des Projektmanagements Die Qualitätssicherung in Projekten wird vom verwendeten Projektmanagement-modell dominiert. Im Vorgehensmodell, abgekürzt V-Modell, ist der Aspekt der Qualitätssicherung sehr fundiert hinterlegt. Das V-Modell und deren Weiterentwicklung V-Modell-XT stellen eine umfassende Sammlung von Wissen über die „Best Practices“ der Softwareentwicklung dar, die insbesondere auch für ILM-Projekte anwendbar sind. Das V-Modell ist ein Prozessmodell, mit dessen Hilfe Projekte gemäß der Norm ISO 9001 abgewickelt werden können. Das V-Modell ist neben dem militärischen Bereich auch für den gesamten Bereich der Bundesverwaltung verbindlich und wird auch von sehr vielen Industriefirmen eingesetzt. Im V-Modell wird das Projektmanagement in Form von Rollen und Prozessen beschrieben. Dies geschieht durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für x Qualitätssicherung (QS), x Konfigurationsmanagement (KM) und x technisches Projektmanagement (PM) anfallen. In der Qualitätssicherung (QS) im Rahmen des Projektmanagements werden die Kernprozesse zur Planung und Durchführung von qualitätssichernden Maßnahmen definiert. Es wird dargestellt, welche Qualität im Projekt auf welche Weise erreicht werden soll (QS-Handbuch). Darüber hinaus dienen die Produkte und Aktivitäten des Vorgehensbausteins der x x x x

Planung (Prüfplan), Vorbereitung (Prüfumgebung, Prüfspezifikation), Durchführung (prüfen) und Dokumentation (Prüfprotokoll)

von Prüfungen.

288

9 Schlüsselfaktor Qualitätssicherung

Abb. 9.4. Projektmanagement-Baustein Qualitätssicherung188

Test- und Prüfaktivitäten werden in den zugehörigen Vorgehensbausteinen (Systemerstellung, SW-/HW-Entwicklung) gehalten. Sind keine entsprechenden Entwicklungsaktivitäten vorhanden, entfallen auch die dafür notwendigen Prüfaktivitäten. Alle formalen Prüfungen müssen im Gegensatz zu den Entwicklertests durch einen unabhängigen Prüfer (zum Beispiel Entwicklerkollegen) durchgeführt und nachvollziehbar sein (Prüfspezifikation, Prüfprozedur, Prüfprotokoll). Für formale Prüfungen gilt generell, dass der Ersteller eines Produkts dieses nicht selbst formal prüfen darf („Vier-Augen-Prinzip“). Die Regelungen des Vorgehensbausteins Qualitätssicherung berühren in keiner Weise organisatorische Festlegungen. Das heißt, qualitätssichernde Aufgaben müssen nicht zwingend in einer eigenen, zentralen Organisationseinheit QS durchgeführt werden, sondern können sehr wohl im Rahmen der Entwicklung dezentral in den einzelnen Teilprojekten erfolgen, jedoch mit der Einschränkung des „Vier-Augen-Prinzips“. Die Vorteile der Prallelität von Projektmanagement und Qualitätsmanagement insbesondere für ILM-Projekte werden im Buch „Information Lifecycle Management – Prozessimplementierung“ ausführlich vorgestellt und kommentiert. Ist für Systemprodukte (Systemteile, SW, HW) keine QS vorgesehen, so gehen diese Produkte nach erfolgreichem Abschluss der Entwicklertests vom Zustand „in Bearbeitung“ in den Zustand „fertig gestellt“ über. Produkte, für die eine Qualitätssicherung vorgesehen ist, gehen nach erfolgreicher Prüfung vom Zustand „vorgelegt“ in den Zustand „fertig gestellt“ über.  188

V-Modell-XT, www.kbst.bund.de.

9.4 ILM-Qualitätssicherungsplanung

289

9.4 ILM-Qualitätssicherungsplanung Der QS-Plan definiert die von den Projektpartnern zu erbringenden Leistungen im Rahmen der betrieblichen Abnahme für ein entwickeltes ILM-Gesamtsystem. Für jede Komponente ist eine Testvereinbarung im Sinne einer Rahmenvereinbarung abzuschließen. Sofern diese Aufträge wesentlich das Gesamtsystem beziehungsweise Inhalte der Rahmentestvereinbarung verändern, muss eine neue Testvereinbarung abgeschlossen werden. Die QS-Planung umfasst damit alle für das Projekt gültigen generellen Festlegungen zur Sicherstellung der geforderten Qualität, zur Prävention und zur Nachweisführung. Geplant werden alle x konstruktiven Maßnahmen zur Erreichung der Qualitätsziele, x präventiven Maßnahmen zur Vermeidung von Qualitätsrisiken und x analytischen Maßnahmen zum Nachweis der Erfüllung von Qualitätsforderungen. Für die Überführung in die konsolidierte Zielumgebung im Rahmen eines ILM-Projektes sind die nachfolgenden Anforderungen aufgeführt.

9.4.1 Installation Neusysteme Die Installation der Neusysteme beinhaltet die Basisinstallation der beiden Speichersysteme und deren initiale Konfiguration. Weiter gehört zu diesem Baustein die Installation der Softwarepakete und der benötigten Host-Agenten auf den vom Projekt betroffenen Hostsystemen. Die Installation umfasst: x x x x x

Migration der Applikationen und der Infrastruktur, Change-Management-Prozesse und deren Umsetzung, Aufbau des Supports für den Betrieb, Basisinstallation der Neusysteme, Installation der Softwarepakete.

9.4.2 Migration Die Migration der Systeme erfolgt serverzentriert. Dazu erforderlich sind eine zeitpunktgenaue Dokumentation der von der Migration betroffenen Serversysteme und der auf diesen betriebenen Applikationsinstanzen. Diese wird im Projektverlauf erstellt und kontinuierlich aktualisiert. Die Durchführung der Migration erfolgt durch Mitarbeiter des Projektteams mit den Punkten: x Definition der Migrationsverfahren, der Beschreibung der Abläufe und der Prozesse, x Durchführung der Migration der Infrastruktur (primär der Server),

290

9 Schlüsselfaktor Qualitätssicherung

x Durchführung der Migration entsprechend den geplanten Migrationsverfahren für jede Applikation, x Dokumentation des Speicherkonfigurationsmanagements der Alt-Systeme (Bestandsaufnahme, Performancedaten, Istdokumentation), x Dokumentation des Speicherkonfigurationsmanagements der Neusysteme (Planung, Performanceoptimierung und -hochrechnung).

9.4.3 Change-Management Diese Dienstleistung umfasst die Standardimplementierung der Erweiterung der bereits bestehenden Infrastruktur. Es wird die erweiterte Systemumgebung implementiert, die dem Kunden das Monitoring und Management ermöglicht. Die Managementaktivitäten umfassen die Überwachung (Monitoring, Controlling), die Konfiguration, die Optimierung (Tuning) und die Planung (Kapazitätsplanung).

9.4.4 Implementierungsleistungen Der Implementierungsservice gliedert sich in drei Phasen mit folgenden Inhalten:

9.4.4.1 Phase 1: Planung und Design In dieser Phase hat das Implementierungsteam folgende Aufgaben: x Prüfen, ob die für den Betrieb vorgesehenen Server den Minimalanforderungen an Hard- und Software gemäß den Angaben im Product-Release-Notes entsprechen. x Zusammen mit dem Kunden die Hostsysteme für die Installation festlegen und prüfen, ob diese die entsprechenden technischen Voraussetzungen erfüllen. x Sicherstellen, dass die für das Management im Rahmen der Zielkonfiguration vorgesehenen Komponenten (Switches, Hosts, Storage Arrays, etc.) korrekt eingerichtet sind. x Planung und Abstimmung der Test- und Abnahmedokumentation vornehmen. x Planung und Design auch für die Produkte in der erweiterten Zielumgebung durchführen.

9.4.4.2 Phase 2: Implementierung und Test Während der Implementierungs- und Testphase werden die Installationsarbeiten an den im Rahmen des Projektes identifizierten Systemen durchgeführt. Dies bedeutet eine Erweiterung im Vergleich zur bereits bestehenden Systemumgebung. Folgende Punkte sind zu bearbeiten:

9.4 ILM-Qualitätssicherungsplanung

291

x Prüfen und Sicherstellen der Netzwerk-Connectivity für alle identifizierten Systeme der erweiterten Umgebung, x Überprüfung der Kommunikation, x Erfassung der erweiterten Topologie, x Einrichten von Alarmen entsprechend der Zielkonfiguration, x Einrichten von Data Collection Policies entsprechend der Zielkonfiguration.

9.4.4.3 Phase 3: Dokumentation, Einführung und Abnahme x Übergabe und Review der Installationsdokumentation an den verantwortlichen Ansprechpartner des Kunden, x Durchführung der Tests und Abnahme der Installation mit dem Kunden.

9.4.5 Zielkonfiguration Der Implementierungsservice beinhaltet die Einrichtung folgender Komponenten: x Erstellen der Alarme unter Verwendung von Alarm-Templates mit den der Konfiguration entsprechenden Grenzwerten (Threshold Values). x Zuweisung von Alarmen einzelnen Hosts. Dies beinhaltet nicht die Erstellung von „Management Policies“ oder „Auto Fix Prozeduren“. x Review der „Data Retention Policies”. x Einrichten von „Data Collection Policies“ und „Assignment for Agents“.

9.4.6 Festlegung der Verantwortungsbereiche Um einen verzögerungsfreien Ablauf des Implementierungsservice zu ermöglichen, sind die folgenden Vorgaben rechtzeitig zu erbringen: x Bereitstellung der Informationen über die Hosts, die z. B. für das Management mit den Produkten Microsoft Operations Manager (MOM) und HP-OpenView (HP) vorgesehen sind. Nach entsprechender Information ist sicherzustellen, dass die vorgesehenen Systeme den Anforderungen entsprechen. x Dem Implementierungsteam sind die entsprechenden Zugriffsrechte und Systemprivilegien auf den von der Implementierung betroffenen Systemen zur Verfügung zu stellen, die für die Durchführung der technischen Arbeiten benötigt werden. x Alle Hardware, die von der Implementierung berührt wird, muss in der Supportmatrix und den entsprechenden Kompatibilitätstabellen (Open Systems Support Matrix) aufgeführt sein. x Bereitstellen eines technisch und organisatorisch verantwortlichen Systemadministrators als Ansprechpartner für die Dauer der Services.

292

9 Schlüsselfaktor Qualitätssicherung

9.5 Qualitätsziele 9.5.1 Qualitätsziele für Hard- und Software Qualitätsziele

ggf. Priorisierung

Funktionalität: Erfüllung der Anforderungen

Hoch

Sicherheit: Zugriffskonzept

Entfällt

Zuverlässigkeit: (Angemessene) Fehlertoleranz Wiederherstellbarkeit

Hoch Entfällt

Benutzbarkeit: Verständlichkeit Intuitive Bedienerführung Online-Hilfe

Entfällt Entfällt Entfällt

Effizienz: Antwort- und Verarbeitungszeiten Wartbarkeit Übertragbarkeit / Portierbarkeit

Hoch Mittel Hoch

Dokumentation: Vollständigkeit Rechtschreibung, Grammatik, Ausdruck Eindeutigkeit der Inhalte Geeignete Darstellungsweisen Prüfbarkeit

Hoch Entfällt Entfällt Entfällt Hoch

9.5.2 Qualitätsziele für das Projektmanagement Qualitätsziele Systematisches Projektmanagement: Termintreue Kosten Personalressourcen Abstimmung mit allen Projektbeteiligten und Schnittstellenpartnern Durchführung des Projektes gemäß Projekthandbuch Abstimmung und Dokumentation von Vertragsänderungen und Abweichungen mit dem AG und AN Rechtzeitige Einbeziehung von externen Projektbeteiligten

ggf. Priorisierung Hoch Mittel Mittel Hoch Hoch Hoch Entfällt

9.6 Abnahmeprüfung

293

9.5.3 Projektspezifische Qualitätsziele Qualitätsziele

Teilziele

Projektmanagement

Systematisches Vorgehen Zahl

Systemaufbau

Maßstab

Planungssicherheit

Dauer

Einhaltung der festgelegten Abläufe Nachweis der Anforderungserfüllung an die Entwürfe

Anzahl Anzahl

Qualitätssicherung

Frühzeitige Vorbereitung Zeitpunkt des Abnahmeprozesses Rechtzeitige Erstellung Zeitpunkt der QS- und Prüfpläne

Dokumentation

Dokumentation gemäß QMH Verwendung der Produktmuster Frei von Rechtschreibund Ausdruckfehlern Vollständigkeit der fachlichen Anforderungen

Metrik Abweichungen von der geplanten Dokumentation Abweichung vom geplanten Zeitaufwand Abweichung von den geplanten Kapazitäten Anzahl der Abweichungen Anzahl der Abweichungen Einhaltung der geplanten Termine Einhaltung der geplanten Termine

Gliederungs- Abweichungen von punkte der geplanten Dokumentation Gliederungs- Abweichungen von der punkte geplanten Dokumentation Anzahl Fehler pro Seite Anzahl

Anzahl der Abweichungen

9.6 Abnahmeprüfung Eine Umfrage, die die Mercury Interactive Corporation bei ihren Kunden durchführte, zeigt, dass dem Testen von Softwareanwendungen immer mehr Bedeutung beigemessen wird. Der Grund liegt darin, dass die IT-Systeme immer komplexer werden. Durch systematische Tests soll die Qualität und Zuverlässigkeit der Softwarepakete, auf denen viele Geschäftsprozesse basieren, sichergestellt werden. Die Befragung von 450 Experten ergab, dass 76 Prozent der Befragten von einer wachsenden Zahl von Testprojekten in ihrem Unternehmen berichten. Auch die Zeiträume zwischen einzelnen Testläufen verkürzen sich nach der

294

9 Schlüsselfaktor Qualitätssicherung

Aussage von 71 Prozent der Befragten. Diese notwendigen Überprüfungen erfolgen natürlich nicht grundlos, meist sind neue Implementierungen und Releasewechsel die Auslöser. So gaben 81 Prozent an, dass sie neue Applikationen genau unter die Lupe nehmen, 72 Prozent werden bei wichtigen Updates aktiv und immerhin noch 40 Prozent testen auch Software-Patches und -Modifikationen. Darüber hinaus gaben mit 53 Prozent aller Befragten an, dass ihre Organisation damit befasst ist, Centers of Excellence aufzubauen oder IT-Abläufe zu standardisieren und zu zentralisieren. Ziel dieser Vorhaben ist es, den Prozess zur Bereitstellung von Applikationen sowie deren Qualität zu verbessern. Die Abnahmeprüfungen im Basisumfang stellen grundsätzlich das Minimum einer betrieblichen Abnahme dar. Eine Reduzierung dieser Prüfungen muss von allen Projektpartnern gesondert bestätigt werden.

9.6.1 Unterlagen zum Qualitätssicherungsprozess Im Rahmen eines notwendigen Solution Validation Center Control (SVC-) Prozess ist ein Qualifier Approval (QA) der einschlägigen Projektunterlagen zu erstellen. Mittels des SVC-Prozesses wird sichergestellt, dass vor jeder geplanten Softwareinstallation in einer bestehenden Produktionsumgebung erst eine sorgfältige Planung der Installation erfolgt. Im SVC-Call wird das QS-Projektteam durch die SVC-Mitarbeiter auf potentielle Probleme aufmerksam gemacht, die in kritischen Fällen vor der Installation in einer eigens eingerichteten Testumgebung validiert werden. Zudem gibt es Tipps zur Skalierbarkeit der Installation, der Plazierung von Agenten usw. Zudem gibt es Hinweise zu möglichen Probleme während der Installation und zu dem evtl. notwendigen Roll-backVerfahren.

9.6.1.1 Qualifier Der Qualifier dient zur Aufnahme der gesamten Umgebung (Pre-Site) und ist die Planungsgrundlage für die Implementation. Hier wird erfasst, welche Objekte (Hosts, Speichersysteme, Switches, HBAs, Firmware, Treiber und Softwarestände) sich in der Speicherinfrastruktur befinden, um diese Informationen mit der Supportmatrix der einzelnen Hersteller der Hard- und Softwarekomponenten abzugleichen. Zusätzlich wird die Netzwerkinfrastruktur erfasst.

9.6.1.2 Config Guide Der Config Guide ist eine Dokumentation der Installation. Hier wird detailliert festgehalten, welche Objekte einzubinden sind und auf welchen Servern Agenten zu installieren sind. Der Config Guide dokumentiert den Zustand der Installati-

9.6 Abnahmeprüfung

295

on nach Beendigung aller Aktivitäten. Wichtige Dinge wie Array-Informationen, Microcode- Levels etc. müssen vor der Installation bekannt sein und im ConfigProzess festgehalten werden. Informationen über verteilte Agenten und Server müssen vom IS während der Installation festgehalten werden.

9.6.1.3 Statement of Work Das Statement-of-Work (SOW) beschreibt die Dienstleistung und die Abnahmekriterien. Das SOW ist meist ein Vertragsbestandteil.

9.6.1.4 Projektplan Er wird vom Projektmanager erstellt und dokumentiert u. a. den Zeitpunkt der Durchführung der einzelnen Aktivitäten.

9.6.1.5 Test- und Akzeptanzplan Der Test- und Akzeptanzplan beinhaltet die einzelnen Schritte, anhand der die Funktion der installierten Lösung überprüft und dem Auftraggeber demonstriert wird. Dies gilt für alle Funktionen, auch für die, die nicht im SOWDokument festgehalten wurden.

9.6.2 Aufbau des Qualitätssicherungsplans Der QS-Plan enthält die für ein Projekt gültigen generellen Festlegungen bezüglich der Prävention und der Nachweisführung (Arbeitsweisen, Hilfsmittel, Abläufe). Die QS-Planung umfasst damit alle für das Projekt gültigen generellen Festlegungen zur Sicherstellung der geforderten Qualität für die Vorbereitung der fachlichen Programmabnahme. Geplant werden x konstruktive Maßnahmen zur Erreichung der Qualitätsziele, x präventive Maßnahmen zur Vermeidung von Qualitätsrisiken und x analytische Maßnahmen zum Nachweis der Erfüllung von Qualitätsanforderungen. Durch die regelmäßige Messung und Aufzeichnung dieser produktbezogenen Kennzahlen werden folgende Ziele erreicht: x Der erreichte Qualitätsstand wird dokumentiert. x Abhilfemaßnahmen können eingeleitet werden, wenn sich eine Kennzahl verschlechtert oder die festgelegten Grenzen verletzt werden. x Es können auf ein Merkmal bezogene Verbesserungsziele gesetzt werden.

296

9 Schlüsselfaktor Qualitätssicherung

9.6.2.1 Qualitätsziele an das IT-System Qualitätsziele Teilziele Fachliche Programmabnahme

Betriebliche Abnahme

Richtigkeit: Die richtigen Ergebnisse beziehungsweise Wirkungen werden geliefert Interoperabilität: Fähigkeit, mit dem vorgesehenen Systemen zusammenzuwirken Ordnungsmäßigkeit: Erfüllung von gesetzlichen und behördlichen Vorschriften Sicherheit: Fähigkeit, einen unberechtigten Zugriff zu verhindern Installierbarkeit: Aufwand, der zum Installieren notwendig ist Konformität: Grad, in dem die Software den Normen oder den Vereinbarungen zur Übertragbarkeit entspricht Austauschbarkeit: Möglichkeit, die Software anstelle der spezifizierten in einer anderen Umgebung zu verwenden

Maßstab189 Metrik190 Anzahl der diesbezüglichen Fehler bei der fachlichen und betrieblichen Abnahme Anzahl Fehler bei der Durchführung des Integrationstest Anzahl der diesbezüglichen Fehler bei der fachlichen und betrieblichen Abnahme Anzahl der diesbezüglichen Fehler bei der fachlichen und betrieblichen Abnahme Zeitbedarf für Installation

Anzahl der festgestellten Abweichungen191

Anzahl der Installationen unter verschiedenen Umgebungen

 189 190

191

Der Maßstab ist der Wert, mit dem die Kennzahl gemessen wird. Einige der aufgelisteten Metriken erfordern Kennzahlen, die durch die Mitarbeiter erfasst werden. Dies setzt eine Entscheidung voraus, die den einzelnen Mitarbeiter dazu verpflichtet, seine Aufgaben in einer detaillierten Zeiterfassung zu dokumentieren. Insofern werden im Projekt nur die Kennzahlen ermittelt, für die organisatorische Rahmenbedingungen vorliegen. Dieses Qualitätsziel ist präventiv zu sehen. Derzeit liegen keine Normen oder Vereinbarungen vor.

9.6 Abnahmeprüfung

297

9.6.2.2 Qualitätsziele für Prozesse Qualitätsziele

ggf. Priorisierung

Systematisches Projektmanagement: Termintreue Kosten Personalressourcen Abstimmung mit allen Projektbeteiligten und Schnittstellenpartnern Durchführung des Projektes gemäß Projekthandbuch Abstimmung und Dokumentation von Vertragsänderungen und Abweichungen mit dem AG und AN Rechtzeitige Einbeziehung von externen Projektbeteiligten

Hoch Mittel Mittel Hoch Hoch Hoch Entfällt

9.6.2.3 Projektspezifische Qualitätsziele Qualitätsziele Teilziele Projektmanagement

Maßstab192 Metrik

Systematisches Vorgehen Planungssicherheit

Systemerstellung

Qualitätssicherung

Dokumentation

Einhaltung der festgelegten Entwicklungsmethoden und Werkzeuge Nachweis der vollständigen Anforderungserfüllung an die Entwürfe Frühzeitige Vorbereitung des Abnahmeprozesses Rechtzeitige Erstellung der QS- und Prüfpläne Dokumentation gemäß der QMH Verwendung der Produktmuster Frei von Rechtschreibund Ausdruckfehlern Vollständigkeit der fachlichen Anforderungen

 192

Der Maßstab ist der Wert, mit dem die Kennzahl gemessen wird.

Abweichungen von der geplanten Dokumentation Abweichung vom geplanten Zeitaufwand Abweichung von den geplanten Kapazitäten Anzahl der Abweichungen Anzahl der Abweichungen Einhaltung des geplanten Termins Einhaltung der geplanten Termine Abweichungen von der geplanten Dokumentation Abweichungen von der geplanten Dokumentation Fehler pro Seite Anzahl der Abweichungen

298

9 Schlüsselfaktor Qualitätssicherung

9.6.2.4 Qualitätsrisiken Im Rahmen der Projektplanung werden die Projektrisiken ermittelt (im V-Modell der Punkt PM07), bewertet, priorisiert und Maßnahmen zur Beherrschung der Risiken geplant und regelmäßig überprüft. Die qualitätsbezogenen Risiken und die entsprechenden Maßnahmen zur ihrer Beherrschung übernimmt der QS-Plan. Geplant werden x konstruktive Maßnahmen zur Erreichung der Qualitätsziele, x präventive Maßnahmen zur Vermeidung von Qualitätsrisiken und x analytische Maßnahmen zum Nachweis der vollständigen Erfüllung von Qualitätsforderungen.

9.6.3 Qualitätssicherungsgrundsätze Die bisher geltenden Qualitätssicherungsgrundsätze umfassen: x x x x

Grundsatz der produkt- und prozessabhängigen Qualitätszielbestimmung, Prinzip der frühzeitigen Fehlerentdeckung und -behebung, Prinzip der entwicklungsbegleitenden, integrierten Qualitätssicherung, Prinzip der unabhängigen Qualitätssicherung.

9.6.4 Testverfahren Die Testverfahren für Software sind im ANSI/IEEE-Standard 829 beziehungsweise in ISO 12207 festgelegt. Die Entwicklung der Software erfolgt gemäß den im V-Modell definierten Standards und unter Beachtung der obigen Festlegungen innerhalb der definierten Phasen.

9.6.4.1 Testplanung Planung der Testaufgaben, der Terminsetzung, der Zielsetzungen und der Definition sowie der Abnahmekriterien. Die Testplanung ist dabei ein Teil der allgemeinen Projektplanung. Voraussetzung: Projektplan

9.6.4.2 Testentwurf Konzeption der Testszenarien mit dem Ziel der Festlegung, welche Komponenten und welche Funktionen in welcher Reihenfolge und wie getestet werden. Das Ergebnis ist ein Testkonzept für jede Testphase und für jedes Teilsystem. Voraussetzung: Fachkonzept

9.7 Vorbeugende Qualitätssicherungsmaßnahmen

299

9.6.4.3 Testfallspezifikation Die Testfallspezifikation enthält eine detaillierte Beschreibung jedes einzelnen Testfalls anhand des Fachkonzeptes und des Systementwurfs. Jeder Testfall hat die Erprobung einer oder mehrerer Funktionen auf einer bestimmten Stufe der Softwarearchitektur zur Aufgabe. Jede Testfallbeschreibung umfasst die Definition der Vor- und Nachbedingungen. Voraussetzung: Fachkonzept und UML-Beschreibung

9.6.4.4 Testprozedurerstellung In dieser Phase erfolgt die Umsetzung der definierten Testfälle in formale Testprozeduren, beziehungsweise in die Skripte für die automatische Durchführung der Tests. Pro Testszenario werden dabei die jeweiligen Testfälle generiert. Voraussetzung ist das jeweilige Objektmodell. Voraussetzung: UML-Beschreibung

9.6.5 Testwiederholung Ein zusätzlicher, spezifischer Punkt ist die Testwiederholung. Die Beschreibung der Durchführung und der dabei zu ermitteln zulässigen Ergebnisse einer Testwiederholung erfolgt parallel zur Entwicklung. Ziel der Testwiederholung ist es sicherzustellen, dass unter jeweils gleichen Rahmenbedingungen die sich wiederholenden Tests immer das definierte Ergebnis liefern. Jede Erweiterung, jede Änderung der bestehenden Funktionalität, jede Korrektur und jede Optimierung zieht jeweils einen Test nach sich in Form einer Testwiederholung. Voraussetzung ist der Einsatz eines Versionsmanagements zur Dokumentation jeder Änderungen im Code und der darauf aufbauenden Testwiederholung.

9.7 Vorbeugende Qualitätssicherungsmaßnahmen 9.7.1 Konstruktive QS-Maßnahmen Die vorbeugenden konstruktiven QS-Maßnahmen auf Basis des V-Modells sind die folgenden: x Die Fachseite wird in die Qualitätssicherung der fachlichen Aktivitäten eingebunden, insbesondere bei der Anforderungsanalyse (SE01 im V-Modell) und dem Systementwurf (SE02 im V-Modell). Das Review des fachlichen Grobkonzeptes erfolgt durch die Fachseite. x Ergebnisse werden zeitnah der Fachseite in überschaubaren Teilen zur Verfügung gestellt und mit ihr abgestimmt.

300

9 Schlüsselfaktor Qualitätssicherung

x Verwendung von Dokumentationsrichtlinien/Produktmustern gemäß QMH. x Entstehen im Submodell SE neue Spezifikationen, so werden auch die Prüfspezifikationen frühzeitig erstellt, um die Zielrichtung des jeweiligen Produkts darzulegen und Missverständnissen vorzubeugen. x Sorgfältige Projektplanung in Abstimmung mit der Fachseite. x Enge Abstimmung und Informationsaustausch innerhalb des Projektteams. x Einsatz von objektorientierten Designtools. x Einsatz von KM-Tools zur Identifikation von Softwareelementen, die zur Konfiguration gehören.

9.7.2 Analytische QS-Maßnahmen 9.7.2.1 Organisation der Qualitätssicherung Die Qualitätssicherung wird durch die Projektleitung beziehungsweise durch die beauftragten Projektmitarbeiter direkt gesteuert und überwacht. Damit wird die Qualitätssicherung bereits in einer sehr frühen Phase der Entwicklung verankert.

9.7.2.2 Berichtswesen Im Rahmen des QS-Berichtswesens sind die Prüfprotokolle nach folgenden Kriterien auszuwerten: x Anzahl der Probleme, x Schwierigkeitsgrad bzw. Komplexität der Probleme, x Klassifikation der Probleme. Die Prüfspezifikationen werden so aufgebaut, dass mit ihnen gleichzeitig die Prüfungen protokolliert werden können. Der Empfängerkreis für die Ergebnisberichte umfasst den IT-Projektleiter, den Leiter-QM und die fachliche Abnahme.

9.7.3 Entwicklungsbegleitende Qualitätssicherung Die Qualitätssicherung erfolgt entwicklungsbegleitend. Die jeweils durchzuführen-den Systemtests werden im Dokument Prüfplan Systemtest beschrieben.

9.7.4 Qualitätsanforderungen an das Produkt im Wirkbetrieb Die Kritikalität und die IT-Sicherheit werden in den folgenden Stufen definiert:

9.8 Projektbezogene Qualitätssicherung

301

Art des Fehlverhaltens bei … Stufen Hoch

Mittel

… administrativen Informationssystemen Fehlverhalten macht sensitive Daten für unberechtigte Personen zugänglich oder verhindert administrative Vorgänge (z. B. Gehaltsauszahlung, Mittelzuweisung) oder führt zu Fehlentscheidungen infolge fehlerhafter Daten –

Niedrig Fehlverhalten vermindert Zugang zu Informationen, die regelmäßig benötigt werden Keine Fehlverhalten beeinträchtigt die zugesicherten Eigenschaften nicht wesentlich

… technischen Systemen Fehlverhalten kann zum Verlust von Menschenleben führen

… Realzeitanwendungen Fehlverhalten, das zu fehlerhaften Positionsangaben führen kann

Fehlverhalten kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen Fehlverhalten kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden Fehlverhalten gefährdet weder die Gesundheit von Menschen noch Sachgüter

–

Fehlverhalten, das zum Ausfall von Plandaten führen kann Alle übrigen Arten von Fehlverhalten

9.8 Projektbezogene Qualitätssicherung 9.8.1 Definition der Aufgaben für die Entwickler aus QS-Sicht Um Abhängigkeiten zu reduzieren werden keine Konstrukte vorgesehen, die mit einer Klassen eine Abhängigkeit von den Methoden einer anderen Klasse vorsieht, um ihre Funktion ausführen zu können, und die von zwei unterschiedlichen Entwicklern betreut werden. Alle relevanten Klassen einschließlich ihrer Methoden werden ausschließlich von einem Entwickler betreut. Der einzelne Entwickler hat darauf zu achten, dass jede Klasse, die aus einer Vielzahl einzelner Methoden besteht, die über den Zustand der gemeinsamen Objektattribute miteinander verquickt sind, beim Löschen einer Methode einen Objektzustand hinterlässt, der das Verhalten der Nachfolgemethode nicht beeinflusst.

302

9 Schlüsselfaktor Qualitätssicherung

9.8.2 Durchführung und Dokumentation Bei der Beschreibung sind jeweils die einschlägigen Unified Modeling Language (UML-) Spezifikationen zu berücksichtigen. Die einzelnen Dokumente sind gemäß der jeweiligen Beauftragung im Unterverzeichnis SE abzulegen. Bei der Durchführung sind folgende Festlegungen zu beachten: x Jeder Entwickler hat seine Klassentests entsprechend den definierten Vorgaben durchzuführen und das Testergebnis gemäß der definierten V-Modellkonformen Ablagestruktur unter QS 3 gemäß der V-Modellvorgabe im Versionsmanagement-Tool abzuspeichern. x Jeder Entwickler hat seine Integrationstests entsprechend den definierten Vorgaben durchzuführen und das Testergebnis im VersionsmanagementTool abzuspeichern. x Jeder Systemtester hat seine Systemtests entsprechend den definierten Vorgaben durchzuführen und das Testergebnis im Versionsmanagement-Tool abzuspeichern.

9.8.3 Schnittstellen Die Schnittstellen werden auf Basis der SIA-Norm realisiert und geprüft.

9.8.4 Zu prüfende Produkte Alle Produkte der Submodelle Systemerstellung (SE), Projektmanagement (PM), Qualitätssicherung (QS) und Konfigurationsmanagement (KM) werden im Rahmen entwicklungsbegleitender Selbstprüfungen beziehungsweise informell (durch Gegenlesen) qualitätsgesichert. Eine formale Qualitätssicherung durch den Qualitätssicherungsverantwortlichen entfällt. Im Allgemeinen gelten für objektorientierte Software die gleichen Anforderungen wie für konventionelle, funktionsorientierte Programme. Es müssen repräsentative Testeingabedaten generiert, Zwischenergebnisse geprüft, Ablaufpfade verfolgt und Testergebnisse validiert werden. Die spezifischen Besonderheiten, die es im Rahmen der Prüfung zu beachten gilt, sind im Folgenden beschrieben.

9.8.5 Spezifische Anforderungen an die Prüfung objektorientierter Software Objektorientierte Software kann nur begrenzt mit den Prüfungskonzepten für funktionsorientierte, modulare Software abgedeckt werden. Die signifikantesten Unterschiede im Vergleich zum Konzept der Objektorientierung sind: x Die stärkere Modularisierung führt zu mehr intermodularen Abhängigkeiten. Eine Methode einer bestimmten Klasse kann auch auf Methoden anderer

9.8 Projektbezogene Qualitätssicherung

303

Klassen angewiesen sein, um ihre Funktion ausführen zu können. Diese andere Klasse wird aber von einem zweiten Entwickler betreut. x Eine Klasse kann eine Vielzahl einzelner Methoden beinhalten, die zwar prozedural von einander unabhängig sind, jedoch über den Zustand der gemeinsamen Objektattribute miteinander verquickt sind. So kann die eine Methode einen Objektzustand hinterlassen, der das Verhalten der Nachfolgemethode beeinflusst. x Die Forderung nach Flexibilität im Klassenmodell erfordert eine Vielzahl möglicher Zustände, die unter wirtschaftlichen Gesichtspunkten nicht alle getestet werden können. x Die von den Klassen beschriebenen Objekte können viele mögliche Zustände annehmen. Je komplexer die Objekte sind, je mehr Attribute und Methoden sie haben, umso mehr Zustände können sie annehmen. Auch hier gilt, dass unter wirtschaftlichen Gesichtspunkten nicht alle getestet werden können. Die spezifischen Herausforderungen der Objektorientierung (OO) in der Entwicklungs- und Testphase an Software ist die Funktionsbeschreibung und die Festlegung der jeweils durchzuführenden Tests. Diese sind in den jeweiligen spezifischen Konstrukten begründet: x Kapselung Die Kapselung der Daten und Funktionen in einzelnen abgeschlossenen Objekten mit fest definierten Schnittstellen nach außen bringt für die Prüfung Vorteile. Die Beschreibung ist daher in einer Weise durchzuführen, dass alle Zustände des eingekapselten Objekts spezifiziert werden. Die Prüfung der fachlichen Programmabnahme setzt darauf auf, dass alle Zustände des eingekapselten Objektes entsprechend der Spezifikation validierbar sind. Dabei ist zu beachten, dass die Methoden nicht einfach aufgerufen werden können, da ihre Ausführung vom jeweiligen Objektzustand abhängt und dieser Zustand durch die vorher ausgeführten Methoden geprägt wird. Daher müssen hier alle Kombinationen der Methodenausführungsfolge erprobt werden, da nur auf diese Weise sichergestellt ist, dass die Methoden aufeinander abgestimmt sind. x Vererbung Die Vererbung kann die Durchführung der Tests zur fachlichen Abnahme in der operativen Ausführung komplexer machen. Die jeweiligen Unterklassen verweisen dabei auf die Attribute und Funktionen der Basisklassen. Jede Veränderung in den Basisklassen betrifft auch die entsprechenden Unterklassen und damit auch alle potenziellen Fehler. Demzufolge ist im Rahmen des Versionsmanagements jede Veränderung in den Basisklassen zu dokumentieren und nach Ende der Tests dürfen die bereits getesteten Basisklassen nicht mehr verändert werden. Spezifische Anforderungen an die QS bestehen in der Festlegung der zeitlichen Abfolge der Prüfung, so dass eventuell Fehler aus Veränderungen in den Basisklassen immer noch im Rahmen der Abarbeitung des Testplans erkannt werden können.

304

9 Schlüsselfaktor Qualitätssicherung

x Polymorphie Die Ausführung der Serverklassen auf den einzelnen Objektmaschinen kann nicht im Vorfeld definiert werden. Die Entscheidung zur Laufzeit, welche Funktion in welchem Objekt einen Auftrag zu erledigen hat, macht den Ablauf zu einem nicht herleitbaren Vorgang. Generell gilt bei heterogenen Hardware- und Softwareumgebungen, dass die Tatsache, dass ein Pfad funktioniert, keine Garantie für die korrekte Abarbeitung des alternativen Pfades ist. Deshalb müssen alle Serverklassen, die eine Anforderung bearbeiten können, getestet werden.

9.8.6 Prüfung verteilter Software Nur eine systematische Prüfung, gekoppelt mit automatischen Techniken, ermöglicht insbesondere bei OO-Systemen die Sicherstellung der geforderten Qualität der Entwicklung. Die Prüfung kann aus zeitlicher Sicht in den folgenden Stufen durchgeführt werden: x Methoden In einem objektorientierten System ist die Methode die kleinste testbare Einheit. Eine Prüfung auf der Ebene der Methoden setzt voraus, dass die einzelne Methode aufgerufen wird und ihr Verhalten hinreichend spezifiziert ist. x Klassen Die nächste größere Einheit ist die Klasse. In einer Klasse sind alle Methoden, die einen bestimmten Objekttyp verarbeiten, zusammengefasst beziehungsweise gekapselt. Anhand der Klasse werden Objekte (Instanzen) generiert, verarbeitet und am Ende gelöscht. Getestet wird die Klasse über ihre Schnittstelle beziehungsweise über ihre Methode, angefangen mit dem Konstruktor zur Erzeugung eines Objektes bis hin zum Destruktor, der zur Zerstörung des Objektes dient. Voraussetzung ist auch hier, dass das Verhalten aller Methoden hinreichend spezifiziert ist. x Komponenten: Komponenten sind mehr oder weniger abgeschlossene Klassenmengen, in denen nur sehr wenige Abhängigkeiten zu Klassen in anderen Komponenten bestehen. Ziel der Aufgliederung in der Fachspezifikation ist es, die Funktionen in einer Weise zu definieren, dass zwischen den Komponenten nur definierte Schnittstellen existieren. Zusammen mit den entsprechend herausgearbeiteten Prüfungskriterien aus der Beschreibung der fachlichen Anforderungen, können hier fachlich bewertbare Testergebnisse erzeugt werden.

9.8 Projektbezogene Qualitätssicherung

305

9.8.7 Prüfmethoden Produkte

Prüfmethode(n)

Anwenderforderungen Projekthandbuch Projektplan QS-Plan KM-Plan Technische Anforderungen Systemarchitektur Schnittstellenübersicht Schnittstellenbeschreibung SWPÄ-Konzept, d. h. der Überleitung der Systemanforderungen (SE1.1 bis SE 1.8) in die Nutzung (SE 9.1 bis 9.3) Integrationsplan Prüfplan Software (teil-) Produkte (Gesamt-)System Handbücher

Review Review Review Review Review Review Review, Testfallentwurf, Testen Review Review, Testfallentwurf, Testen Entfällt

Review, Testfallentwurf, Testen Review Review, Testfallentwurf, Testen Review, Testfallentwurf, Testen Review

9.8.8 Entwicklungsphase und ihre Prüfmethoden Produkt/Phase Grobkonzept Projektbeschreibung, Projektplan, QS-Plan, KM-Plan (Planungsdokumente) Systemanforderungen SWPÄ-Konzept Systemarchitektur Schnittstellenübersicht Integrationsplan Technische Anforderungen Spezifikation SW-Architektur der SW-Einheit Schnittstellenbeschreibung SW-Einheit bzw. Datenbank Integrationsplan der SW-Einheit SW-Entwurf je Element

Review Statische Testfall- Testen Bemerkung Analyse Entwurf 9

Abstimmung mit Fachspezifikation (FS) Bestätigung FS Entfällt

9 9 9

9 9 9

9 9 9

9 9

9 9

9 9

9

9

9

9

9

9

306

9 Schlüsselfaktor Qualitätssicherung

Produkt/Phase

Review Statische Testfall- Testen Bemerkung Analyse Entwurf

Realisierung Implementierungsdokumente (SW-Modul/Datenbank) Betriebsinformationen, hier insbesondere(AnwenderundBetriebshandbuch) System (Systemtest) Einführung System im Wirkbetrieb (Betriebl. Prüfung)

9

9

9

9

Die Aktivitäten des Projektmanagements werden durch regelmäßige Sachstands- und Fortschrittsbesprechungen begleitet. Nr. Prüfgegenstand

Prüfmethode(n)

1 2 3 4 5

Review Review, Testfallentwurf, Testen Review, Testfallentwurf, Testen Review, Testfallentwurf, Testen Review, Testfallentwurf, Testen

Planung Adapter Plattform Konsument Migration

9.8.9 Testentwurf Der Testentwurf beschreibt auf der Basis des Fachkonzeptes die Spezifikation der Testanforderungen. Die verschiedenen Anwendungsfälle bilden dabei die Basis. Die aus dem Fachkonzept abgeleiteten funktionalen Testanforderungen beschreiben die einzelnen Testszenarien, die notwendig sind, um den erforderlichen Nachweis zu erbringen, so dass die definierten Systemfunktionen korrekt implementiert sind. Die „nichtfunktionalen“ Anforderungen wie IT-Sicherheit, Performanz und Benutzerfreundlichkeit werden gesondert behandelt, wie bereits dargestellt.

9.8.9.1 Testansatz Klassentest Der Klassentest ist ein interner Testfall. Voraussetzung für dessen Durchführung sind Kenntnisse der Klassenkonstruktion. Klassentests unterschieden sich insbesondere im Testobjekt. Beim Testobjekt Klasse beziehen sich die Endkriterien auf die Eigenschaften der Klasse, z. B. Methoden, Zweige, Parameter, Objektinstanzen und Objektzustände. Das Ziel ist es, diese Eigenschaften bis zu einem gewissen Grad zu bestä-

9.8 Projektbezogene Qualitätssicherung

307

tigen, z. B. durch die Ausführung der Methoden, die Überdeckung der Zweige, die Zuweisung von definierten Parametern, die Erzeugung bestimmter Objektinstanzen und bestimmter Objektzustände. In Abhängigkeit vom konkreten Umfang wird in Abstimmung mit der fachlichen Programmabnahme definiert: x Welche Eigenschaften zu testen sind. x Welcher Umfang zu testen ist (z. B. bis zu 100 Prozent aller Methoden, aller Zweige usw.). Beim Testobjekt Komponente sind die Endkriterien Maße für die Überdeckung der Komponentenfunktionen. In Abhängigkeit vom konkreten Umfang wird in Abstimmung mit der fachlichen Programmabnahme definiert: x Welche Eigenschaften zu testen sind. x Welcher Umfang zu testen ist (z. B. bis zu 100 Prozent aller Funktionen). Der Klassentest ist ein Test der Klasse gegen die Klassenspezifikation. Die einzelnen Klassentestfälle werden aus der Klassenspezifikation abgeleitet. Der Entwickler führt die zu definierenden Klassentests entsprechend der jeweiligen Anforderung in folgender Form durch: x Test über Testtreiber, x Built-in-Test, x Hierarchisch-inkrementeller Test.

9.8.9.2 Testansatz Integrationstest Auch Integrationstests sind interne Tests. Die Durchführung der Integrationstests setzt Kenntnisse der Komponentenschnittstelle voraus. Ziel der Integrationstests ist es, die Schnittstellen zwischen den internen Komponenten zu überprüfen. Der Entwickler führt den definierenden Integrationstest durch. Auf der Stufe des Integrationstests sind die Testfälle in der Regel Nachrichten von einer Klasse beziehungsweise Komponente an eine andere. Dazu werden bestimmte Methoden angesteuert, die in der Regel nicht nur einer Klasse angehören. Die Methoden sind verteilt auf mehreren Klassen einer Komponente. Der Integrationstestfall baut demzufolge auf der Schnittstelle auf. Die Argumente sind die Parameter in der Schnittstelle, die globalen Daten beziehungsweise die persistenten Objekte und bei den Adaptern die Inhalte der Konsumenten-DB, auf welche die Komponente zugreift. Integrationstestfälle müssen aufeinander aufbauen, um die Initialisierung der internen Datenzustände einer Komponente bei jedem Testfall zu vermeiden. Die operative Durchführung erfolgt in Form des Bottom-up-Ansatzes. Dabei werden die Klassen zuerst getestet, deren Operationen keine Operationen anderer Klassen aufrufen. Die Testfälle können somit über Operationsaufrufe realisiert werden. Dann folgt die nächste Stufe in der Hierarchie. In der zweiten Stufe werden die Klassen getestet, deren Operationen die Operationen der bereits getesteten Klassen aufrufen usw., bis die oberste Basisklasse

308

9 Schlüsselfaktor Qualitätssicherung

getestet werden kann. Der Integrationstest ist ein Test der Systemarchitektur gegen die Spezifikation der Systemarchitektur. Die Integrationsfälle werden aus der Architektur abgeleitet. Dabei wird lediglich der jeweilige Rückgabewert getestet. Der Entwickler führt die zu definierenden Integrationstests durch. In Abhängigkeit vom konkreten Umfang wird in Abstimmung mit der fachlichen Programmabnahme definiert: x Welche Klassen zu testen sind. x Welcher Umfang zu testen ist.

9.8.9.3 Testansatz Systemtest beziehungsweise fachliche Programmabnahme Systemtestfälle sind externe Testfälle, bei denen das System über eine Schnittstelle getestet wird. Zur Spezifikation der Systemtestfälle sind Kenntnisse der Anwendungen erforderlich. Der Systemtester prüft das System gegen die Systemanforderungen. Die Systemtestfälle werden aus dem Fachkonzept abgeleitet und vom QS-Verantwortlichen durchgeführt. In Abhängigkeit vom konkreten Umfang wird in Abstimmung mit der fachlichen Programmabnahme definiert: x Welche Funktionen beziehungsweise Services zu testen sind. x Welcher Umfang zu testen ist. Ziel ist es, die Systemtests weitestgehend automatisiert durchzuführen.

9.8.9.4 Ableitung der Testfallspezifikation aus der UML-Darstellung Zwischen der Fachspezifikation (Fachkonzept, IT-Konzept) und der Spezifikation der Testfälle besteht ein sehr enger Zusammenhang (die zwei Seiten der gleichen Medaille), auf der einen Seite die Planung, so soll es funktionieren, und auf der anderen Seite die entsprechende Beweisführung, wie es wirklich funktioniert. Die Zusammenhänge zwischen der Unified Modeling Language (UML-) Beschreibung und den Testfällen sind wie folgt: x UML-Klassendiagramm, -Aktivitätsdiagramm und -Zustandsdiagramm stellen den Input für die Spezifikation der Klassentestfälle dar. x UML-Komponentendiagramm, -Sequenz- und/oder -Kollaborationsdiagramm sowie Klassendiagramm stellen den Input für die Spezifikation der Integrationstestfälle dar. x UML-Anwendungsdiagramm (Use Case) und -Komponentendiagramm stellen den Input für die Spezifikation der Systemtestfälle dar.

9.8.9.5 Kontrolle des Änderungsmanagements Alle Änderungen werden als Change Request (CR) eingesteuert. Durch das Änderungsverfahren im Änderungsmanagement ist sichergestellt, dass Änderungen in die entsprechende Dokumentation einfließen und neue Versionen

9.8 Projektbezogene Qualitätssicherung

309

erzeugt werden. Das Änderungsmanagement selbst ist im gemäß V-Modell im KM-Plan festgelegt.

9.8.9.6 Kontrolle von Bearbeitungskompetenzen Die Zugriffsrechte selbst wurden im KM-Plan festgelegt. Die Verwaltung und Überprüfung geschieht durch den Entwicklungsadministrator. Die Kontrolle der Bearbeitungskompetenzen erfolgt stichprobenartig über die Protokollierung der Zugriffe beziehungsweise über die Änderungsnachweise.

9.8.9.7 QS-Berichtswesen Im Rahmen des QS-Berichtswesens sind die Prüfprotokolle nach folgenden Kriterien auszuwerten: x Anzahl der Probleme, x Schwierigkeitsgrad bzw. Komplexität der Probleme, x Klassifikation der Probleme. Das Ergebnis der Überprüfung ist eine Abnahmeerklärung. Die Abnahmeerklärung ist nur gültig, wenn beide Kooperationspartner unterschrieben haben. Eine detaillierte Beschreibung eines Qualitätsberichts findet sich im Band II „Information Lifecycle Management – Prozessimplementierung“. Wir beschreiben dort ausführlich ein ILM-Projekt in allen relevanten Details.

10 Schlüsselfaktor Risikomanagement

10.1 Risikomanagement versus Qualitätsmanagements Als traurige Beispiele für IT-Projekte, die aus dem Ruder liefen, sorgten sowohl Toll Collect als auch das Internetportal der Bundesagentur für Arbeit für unrühmliche Schlagzeilen. Beide Projekte sind aber keine Einzelfälle. Eine Studie der Standish Group belegt, dass lediglich 28 Prozent der IT-Projekte im vorgegebenen Kosten- und Zeitrahmen beendet werden.193 Projekte, die aus dem Ruder laufen, können sehr schnell Schäden in mehrstelliger Millionenhöhe zur Folge haben. Um dem entgegenzuwirken, beschäftigt sich das IT-Risikomanagement mit der Steuerung und Überwachung solcher Bedrohungen. Ein Innovationsprojekt wie ILM bewegt sich selbstverständlich in einem Spannungsfeld zwischen Gefahren und Chancen. Gefahren gefährden den Projekterfolg, Chancen ermöglichen ihn. Zur Erreichung der notwendigen Qualität müssen Abweichungen von den festgelegten oder vorausgesetzten Erfordernissen vermieden werden. Fehlervermeidung in einem ILM-Projekt erfolgt durch das Management des Fehlerrisikos. Die Nichterfüllung der Anforderungen ist ein Fehler und damit eine Gefahr für den Projekterfolg. Zur Erreichung des Projekterfolgs müssen daher die Risiken berücksichtigt und behandelt werden, d. h., ein Risikomanagement ist notwendig. Qualitätssicherung und Risikomanagement sind eng verbunden. Damit ist das Risikomanagement ein Teil des Qualitätsmanagementprozesses. Gleichzeitig ist die Qualitätssicherung aber auch eine wichtige Methode der Risikominderung und damit des Risikomanagementprozess. Die Qualitätssicherung in Verbindung mit dem Risikomanagement ist somit ein Schlüsselfaktor in jedem ILM-Konzept. Das Bewusstsein für Qualitätssicherung, für Risikomanagement und, wie bereits beschrieben, für IT-Sicherheit ist leider meist nicht sehr stark im Bereich IT entwickelt. Durch das immer stärkere Gewicht der IT innerhalb der unternehmenskritischen Geschäftsprozesse und der möglichen Haftungsrisiken trotz der Einhaltung von Normen wächst aber das Risiko, dass auch Fehler in der Leistungserbringung des Ist-Service erhebliche wirtschaftliche Auswirkungen haben. Ein wichtiger Punkt insbesondere innerhalb jedes ILM-Konzeptes ist deshalb die

 193

Standish Group, www.standishgroup.com.

312

10 Schlüsselfaktor Risikomanagement

kontinuierliche Qualitätssicherung (QS) in Verbindung mit einem entsprechenden Qualitäts- und Risikomanagements. Obwohl die Aufgabe des Risikomanagements und die damit verbundene Risikostrategiebildung im Problembewusstsein deutscher IT-Führungskräfte fest verankert sind, wird die Absicherung von Wirtschaftlichkeits- und Effizienzzielen durch das Risikomanagement in der Praxis stark vernachlässigt. Eine Studie von Krcmar brachte zutage, dass die Bewältigung von Projektrisiken und von strategischen Bedrohungen eher selten zum Aufgabenbereich des IT-Risikomanagements gezählt werden. Der Wissenschaftler zeigte damit, dass es deutliche Verbesserungspotenziale im Bereich der Risikoberichterstattung gibt. Besonderer Handlungsbedarf besteht laut der Studie von Krcmar bei der ökonomischen Bewertung von Risiken und der damit verbundenen Möglichkeit, Chancen und Risiken sinnvoll gegeneinander abzuwägen. In einem wertorientierten Unternehmensmodell muss sich die Aufgabe des IT-Risikomanagements daher von einem reinen Sicherheitsmanagement hin zu einer betriebswirtschaftlichen Gestaltungs- und Optimierungsfunktion entwickeln. Die Innovation ILM muss als Investition ohne Erfolgsgarantie angesehen werden, die gleichermaßen Chancen wie Risiken beinhaltet. Zum spezifischen Innovationsrisiko, d. h., die Innovation leistet keinen Beitrag zum betrieblichen Erfolg, treten bei ILM-Projekten die allgemeinen Projektrisiken, die aufgrund des innovativen Projektcharakters erhöht sind bezüglich: x x x x

Kostenrisiken, Ressourcenrisiko, Zeitrisiko und technisches Risiko.

Das Risikomanagement muss sich deshalb primär an den Schlüsselfaktoren des Projektes orientieren. Für ILM-Projekte bedeutet dies insbesondere, dass ausgehend von der strategischen IT-Infrastrukturplanung das strategische Einführungskonzept für ILM ein zentrales Feld des Risikomanagement darstellt. Dabei wird ILM als Prozessmodell und als Modell mit dem Fokus auf die Speicherung von Informationen dargestellt. Der abgeleitete Schlüsselfaktor Klassifizierungskonzept befasst sich mit dem anspruchsvollsten Moment der Einführung von Information Lifecycle Management – der Klassifizierung unstrukturierter Daten und der Automatisierung der Informationszuordnung zu Datenklassen. Der Schlüsselfaktor ITSicherheit stellt eine grundlegende Voraussetzung für Compliance dar. Das Risikomanagement eines innovativen ILM-Projektes muss im Gegensatz zum allgemeinen Risikomanagement nicht nur die bekannten Risiken behandeln, sondern zusätzlich die unbekannten und neuartigen Risiken identifizieren und handhaben. Im Wesentlichen ist es das Ziel, die vorhandene Flexibilität zu erhalten, neue Handlungsmöglichkeiten zu eröffnen und die notwendige Transparenz im Sinne eines Frühwarnsystems zu schaffen.

10.2 Grundlagen des Risikomanagementprozesses

313

10.2 Grundlagen des Risikomanagementprozesses Die gesetzlichen Grundlagen im Kontext des Risikomanagements werden im Wesentlichen durch drei Komponenten bestimmt: x KonTraG, x Produkthaftung sowie x ISO- und DIN-Normen. Im Rahmen der Verschuldungshaftung nach § 823 BGB haftet der Hersteller eines fehlerhaften Produktes auch für nicht voll beherrschbare Risiken. Insbesondere die DIN/ISO 9000-Normenreihe befasst sich im Zuge der Qualitätssicherung auch mit der Fehlervermeidung und dem Risikomanagement. Die DIN 69901 definiert das Projektmanagement, zu dem auch das Projektrisikomanagement gehört. Die DIN 25448 (Ausfalleffektanalyse) und die DIN 25424 (Fehlerbaumanalyse) befassen sich mit Fehlern und dem Risiko solcher Fehler. Das Risikomanagement umfasst alle Aktivitäten zum Umgang mit den Projektrisiken. Die spezifischen Aufgaben des Risikomanagements im Rahmen eines ILM-Projektes sind: x die Informationsaufgabe zur Schaffung von Transparenz sowie x die Aktionsaufgabe zur Schaffung von Handlungs- und Reaktionsspielräumen. Aus diesen Aufgaben lassen sich verschiedene Aufgabenfelder herunterbrechen, wobei bezüglich Nomenklatur und Gliederung in der Literatur keine Einigkeit herrscht. Hier kann nur auf die verschiedenen Ansätze von Boehm (1989), Burghard (2002), Brühwiler (2003), Charette (1989), Demacro/Lister (2003), Horva’th (2002, Versteegen (2003), Wallmüller (2004), Williams/Walker/Dorofee (1997) und Wolf (2003) verwiesen werden. Trotz der Unterschiede in den verschiedenen Modellen lassen sich drei wichtige, quasi allgemein verbindliche Aufgabenfelder eindeutig identifizieren: x Beschaffung von Risikoinformation durch Identifikation, Analyse, Bewertung und Priorisierung, x Behandlung von Risiken durch geeignete Maßnahmen, x Kontrolle des Prozesses.

10.2.1 Risikomanagement für die Innovation ILM Da der Wertschöpfungsprozess in vielen Unternehmen zunehmend von der rechtzeitigen Bereitstellung von Information und entsprechenden IT-Prozessen abhängt, sollte die traditionelle Trennung von allgemeinem Risikomanagement und spezifischem IT-Risikomanagement zugunsten einer ganzheitlichen Betrachtung weichen. Die Formeln für das Risikomanagement scheinen dabei sehr simpel: x „Bedrohung u Schwachstelle u Kosten“ oder x „Schadenshöhe u Eintrittswahrscheinlichkeit“.

314

10 Schlüsselfaktor Risikomanagement

Die Probleme entstehen erst bei der konkreten Anwendung. Viele Unternehmen kennen weder die Eintrittswahrscheinlichkeit eines IT-Schadensfalls noch die Geschäftswerte ihrer IT-Infrastruktur, geschweige denn die potenzielle Schadenshöhe. Für die Bestimmung eines IT-Risikos muss aber bekannt sein, welche Rolle eine bestimmte Information in einem bestimmten Geschäftsprozess spielt. An Backup und Restore führt also kein Weg vorbei, bilden sie doch eine Art von Überlebensversicherung. Die Realität sieht leider anders aus. Laut einer Studie von Winmark/Quantum sichert rund ein Drittel der befragten Unternehmen geschäftskritische Daten nur einmal in der Woche. Kein Wunder, dass nur 36 Prozent ihren Backup-Systemen zu 90 bis 100 Prozent vertrauen. Die restlichen 64 Prozent gehen ein Höchstrisiko ein und bereiten sich nicht auf den selbst erzeugten „Größten anzunehmen Unfall“ (GAU) vor. Laut der DataquestStudie liegen die Ausfallkosten für Unternehmen in der Telekommunikationsbranche bei 7,7 Mio. Euro pro Stunde. Wertpapierhändler kommen auf 3,3 Mio. Euro, Versandhäuser noch auf 46.000 Euro pro Stunde.194 Zwar gibt es in der betrieblichen Praxis erprobte Methoden wie die Control Objectives for Information und Related Technology (COBIT), den CISA-Ansatz, die Audit-Checkliste des Bundes der Deutschen Revisoren und den BSI-ITGrundschutz, die jedoch im konkreten Anwendungsfall bedingt durch verschiedene Einschränkungen keine entscheidende Rolle spielen können. Dagegen sind gesunder Menschenverstand in Verbindung mit Pragmatismus im praktischen Einsatz von ausschlagender Bedeutung. Die vorgestellten Ansätze stellen gleichwohl Hilfsmittel zur Beurteilung der Kritikalität und der Ursache-WirkungsBeziehungen einer Störung sowie möglicher Kaskadeneffekte zur Verfügung. Alle rationalen Argumente sprechen also für ein ausgefeiltes IT-Risikomanagement mit einer ebenso ausgefeilten Backup- und Recovery-Strategie. Auch wenn das IT-Risikomanagement nicht direkt zum Unternehmenserfolg beiträgt, vor Ereignissen schützt, die eventuell nie eintreten, technisch komplex ist und Betreuung und Kontrolle benötigt: Ohne Backup und Recovery gehen Unternehmen ein nicht zu rechtfertigendes Risiko ein. Deshalb sollten sie gesetzliche Vorgaben und Richtlinien zum Risikomanagement als Chance begreifen und nicht als aufgezwungene Pflichtübung. Bereits nach der Gewerbeordnung sind sie dazu verpflichtet, ihre IT-Infrastruktur so zu gestalten, wie es zu einer ordentlichen Durchführung der Geschäfte notwendig ist. Regulative Vorgaben wie das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) legen nicht nur nahe, sich stärker auf das IT-Risikomanagement zu konzentrieren, sondern auch zu dokumentieren, wie diese Anforderungen umgesetzt werden. Unternehmen ohne IT-gestütztes Risikomanagement werden durch Basel II künftig schwieriger oder zu ungünstigeren Konditionen an Kredite der Banken kommen. Gleichzeitig werden sich mit Solvency II die Prämien der Versicherungen stärker an den tatsächlichen Risiken ausrichten und dann im Zweifelsfall steigen. Viele Unternehmen besitzen Tools, die sie für die beschriebenen Aufga

194

Dataquest, www.dataquest.com.

10.2 Grundlagen des Risikomanagementprozesses

315

ben wirkungsvoll einsetzen könnten, jedoch es fehlt meist das entsprechende Know-how. De facto sind die im Einsatz befindlichen Überwachungs-Tools, wie z. B. MOM, HP-OpenView, in Verbindung mit Datenanalyse-Werkzeugen in Überwachungs-Cockpits ideale Hilfsmittel zur Identifizierung finanzieller Risiken. Insbesondere die Verbindung mit Tools im Bereich Servicemanagement erleichtert das Erkennen operativer Problemsituationen. Alles spricht also für ein Risikomanagement mit Backup, Recovery, Notfallplänen und einer umfassenden Dokumentation der getroffenen Maßnahmen. Am besten starten Anwender ihr Projekt für das IT-Risikomanagement, wenn sie zunächst den Wert der einzelnen Daten ermitteln. Nur wenige Unternehmen kennen den Geschäftswert ihrer Datenbestände und nicht alle von ihnen weniger stimmen die Kosten für den Datenschutz mit dem Wert dieser Daten ab. Die akzeptablen Ausfallzeiten richten sich danach, wie wichtig die Daten für die Geschäftsprozesse sind. Geschäftskritische Daten wie beispielsweise Bestellungen von Kunden müssen schneller wiederhergestellt werden als die Umsatzsteuervor-anmeldung vom vorletzten Quartal. Die Relevanz der Datenbestände bestimmen Anwender, indem sie errechnen, was Ausfallzeiten oder ein kompletter Datenverlust kosten würden. Neben den entsprechenden Softwarelösungen erfordert das IT-Risikomanagement vor allem eine sorgfältige Planung. Hier können Interessenten beispielsweise auf den DRBC-Leitfaden (Disaster Recovery / Business Continuity) des Georgia Institute of Technology zurückgreifen. Dieser Leitfaden empfiehlt IT-Anwendern folgendes Vorgehen: x Stellen Sie ein Team zusammen. Wichtig sind die Zusage und Unterstützung des Firmenchefs, ein funktionsübergreifender Lenkungsausschuss sowie ein Kernarbeitsteam. x Analysieren Sie Ihr Unternehmen. x Identifizieren Sie seine Ziele, seine Leistungen, Prozesse und Ressourcen sowie die Risiken, denen es ausgesetzt ist, die möglichen Auswirkungen dieser Risiken und die Institutionen (z. B. Technologieanbieter), an die Sie sich zur Risikoverringerung wenden. x Definieren Sie eine Strategie für Disaster Recovery und Business Continuity für das gesamte Unternehmen, seine Geschäftsprozesse und Ressourcen. x Lösen Sie anschließend die Frage der Finanzierung. x Entwickeln Sie einen detaillierten Plan. Definieren Sie seinen Umfang und dokumentieren Sie die Anforderungen ausführlich. x Implementieren Sie Ihren Plan. Zu den erforderlichen Schritten gehören die Sicherstellung der unternehmensweiten Unterstützung, die Entwicklung der Implementierungsdokumentation, die Zuweisung von Funktionen und Verantwortungen, die Schulung der Mitarbeiter sowie das Testen der implementierten Komponenten. x Verwalten Sie Ihren Plan. Sie benötigen einen Prozess für das ChangeManagement sowie eine Möglichkeit, das Leistungsverhalten zu überwachen und Benchmark-Tests für neue Anwendungen, Produkte und Prozesse durchzuführen.

316

10 Schlüsselfaktor Risikomanagement

Der Schlüssel zum IT-Risikomanagement ist das Planen, Schulen, Testen und regelmäßige Prüfen des Plans. Dies kann aber nur funktionieren, wenn IT und die einzelnen Fachabteilungen Hand in Hand arbeiten. Unternehmen, die dieses Vorgehen aktiv umsetzen, schließen einen Datenverlust weit gehend aus. Katastrophenszenarien verlieren ihren Schrecken, ob Hackerangriff, Hardwaredefekt oder fehlerhaftes Löschen beziehungsweise Überschreiben einer Datei. Die Analysten der Aberdeen Group stellen derzeit einen Trend in den Unternehmen zum Aufbau von „Information-Value“-Teams fest, die sich mit allen Fragen des Datenmanagements beschäftigen, Rollen und Verantwortlichkeiten zuordnen und eine Art Business-Plan erstellen für den Umgang mit den Informationen, die das Unternehmen produziert.195 Aber auch verschiedene Anbieter helfen ihren Kunden, ihre Daten nach unternehmerischen Gesichtspunkten zu bewerten und die dafür technologisch am besten geeigneten Datensicherungsverfahren zu verifizieren – bei der Datensicherung ist die Strategie „one size fits all“ nicht anwendbar. Sie unterstützt Unternehmen, die folgende Aufgabenstellungen unter Business-Aspekten lösen wollen: x Integration der sich ständig ändernden Benutzerinfrastruktur für Anwenderdaten in ein übergreifendes Konzept, x Integration von Hochverfügbarkeit beziehungsweise Datenreplikation für unterschiedlichste Datentypen, x Einbindung in ein holistisches, unternehmensweites Speichermanagementkonzept.

10.2.2 Risikomanagement im Projektmanagement 10.2.2.1 DIN 69901 Nach DIN 69901 ist das Projektmanagement die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes. Risikomanagement gehört damit zu den Aufgaben des Projektmanagements.196 Das Projektmanagement, insbesondere in einem ILM-Projekt, muss somit den Teil des Risikomanagements abdecken, der die projektinternen Risiken betrifft. Diese Aufgabe gehört zu den zentralen Zuständigkeiten des Projektmanagements. Projektrisikomanagement ist eine Teilaufgabe des Projekt-Controllings.

10.2.2.2 Risikomanagementmodell des Software Engineering Institute Das Risikomanagement-Paradigma des Software Engineering Institute (SEI) ist aus dem „Plan-Do-Check-Act“ (PDCA-) Zyklus des Projektmanagements abgeleitet. Die einzelnen Schritte sind: x Identifikation der Risiken, x Analyse der Risiken,  195 196

Aberdeen Group, www.aberdeen.com. Littkeman 2006, Burghard 2002, DeMarco/Lister 2003.

10.2 Grundlagen des Risikomanagementprozesses

317

x Planung der Maßnahmen, x Nachverfolgung (Tracking) der Risiken, x Steuern (Control) und Anpassen der Pläne. Neben diesen Punkten wird die Kommunikation der Risiken betont, die zur Risikotransparenz und zur Aufmerksamkeit für die Risiken führen soll. Der Zyklus des Risikomanagements wird während der Laufzeit des Projektes wiederholt durchlaufen und ständig aktualisiert.

10.2.2.3 Risikomanagement-Modell nach CMM/CMMI Das Capability Maturity Model (CMM) und sein Nachfolger Capability Maturity Model Integration (CMMI) dienen zur Einordnung der Prozesse eines Unternehmens entsprechend ihres Reifegrades. Beide Modelle wurden vom Software Engineering Institute entwickelt. In der Stufenbeschreibung des CMM/CMMI wird festgelegt, welche Eigenschaften die Prozesse zur Erreichung einer bestimmten Stufe erfüllen müssen. Die Stufen des Modells lauten: 1. 2. 3. 4. 5.

Initial, Managed; grundlegendes Projektmanagement, Defined; Prozessstandardisierung, Quantitatively managed; Messung aller Prozessparameter, Optimizing; kontinuierliche Prozessverbesserung.

Jede dieser Stufen hat exakte Vorgaben bezüglich der zu implementierenden Prozesse. Risikomanagement ist bei CMM ab Stufe 2 in Form von Continous Risk Management und Team Risk Management gefordert. Im CMMI ist ein vollständiges Risikomanagement Teil der Stufe drei und besteht aus den folgenden Bereichen: x Risikomanagement vorbereiten, x Risiken identifizieren und analysieren, x Risiken behandeln und mindern.

10.2.2.4 Risikomanagement im Rahmen des V-Modells Das im Rahmen des Projektmanagements (siehe Kap. 9.3) bereits vorgestellte V-Modell behandelt das Thema Risikomanagement in erster Linie unter dem Gliederungspunkt des Projektmanagements. Es werden im V-Modell folgende Risiken berücksichtigt: x x x x x x

Planungsbedingte Risiken, Technische Risiken, Qualitätsbezogene Risiken, Vertragliche Risiken, Finanzielle Risiken, Projektspezifische Risiken.

318

10 Schlüsselfaktor Risikomanagement

Tabelle 10.1. Risikomanagement im Rahmen des V-Modells197 PM-Aktivitäten PM 1

Projektinitialisierung

PM 2

Vergabe/Beschaffung

PM 3

Auftragnehmer-Management

PM 4

Feinplanung

PM 5

Kosten-/Nutzenanalyse

PM 6

Durchführungsentscheidung

PM 7

Risikomanagement

PM 8

Projektkontrolle und -steuerung

KM 4.7

Projekthistorie führen

PM 9

Informationsdienst/Berichtswesen

PM 10

Schulung/Einarbeitung

PM 11

Bereitstellung der Ressourcen

PM 12

Vergabe von Arbeitsaufträgen

PM 13

Einweisung der Mitarbeiter

PM 14

Projektabschluss

Die Aktivitäten beziehen sich wie bei den anderen Modellen auf den Informationsteil (Risiken erkennen und bewerten) und auf den Maßnahmenteil (Maßnahmen definieren, priorisieren, anwenden und kontrollieren). Das Risikomanagement wirkt direkt mit den Modulen „Projektkontrolle“ und „Feinplanung“ zusammen. Im V-Modell ist somit das Risikomanagement in eine vollständige Prozesslandschaft für ein Entwicklungsprojekt eingebettet. Projektmanagement basierend auf dem V-Modell schafft damit erst die Voraussetzung, anspruchsvolle Projekte wie die ILM-Einführung erfolgreich durchführen zu können.

10.2.2.5 Risikomanagement im Rahmen des V-Modell-XT Im Jahr 1997 wurde das V-Modell 97 fertig gestellt und seitdem nicht weiter fortgeschrieben. Daher spiegelt es im Jahr 2004 nicht mehr den aktuellen Stand der Informationstechnologie wider. Neuere Methoden und Technologien wie die komponentenbasierte Entwicklung oder der Test-First-Ansatz werden im V-Modell 97 nur bedingt berücksichtigt. Zudem wurden im Umgang mit dem V-Modell 97 umfangreiche Erfahrungen gesammelt und Verbesserungsvorschläge erarbeitet. Vor diesem Hintergrund haben das Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr (IT-AmtBw A5) und die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (BMI-KBSt) die Entwicklungsstandards für  197

V-Modell, http://de.wikipedia.org/wiki/V-Modell, www.kbst.bund.de.

10.2 Grundlagen des Risikomanagementprozesses

319

IT-Systeme des Bundes auf Basis des V-Modells 97 weiterentwickelt. Vom Inhalt und Umfang des V-Modells 97 ausgehend wurden dabei die folgenden Anforderungen umgesetzt: x Verbesserung folgender Qualitätseigenschaften: Möglichkeit zur Anpassung an verschiedene Projekte und Organisationen, Anwendbarkeit im Projekt, Skalierbarkeit auf unterschiedliche Projektgrößen sowie Änder- und Erweiterbarkeit des V-Modells selbst, x Berücksichtigung des neuesten Stands der Technologie und Anpassung an aktuelle Vorschriften und Normen, x Erweiterung des Anwendungsbereiches auf die Betrachtung des gesamten Systemlebenszyklus bereits während der Entwicklung, x Einführung eines organisationsspezifischen Verbesserungsprozesses für Vorgehensmodelle. Mit der V-Modell-XT-konformen Durchführung von Projekten werden zwei wesentliche Ziele verfolgt: x Minimierung der Projektrisiken Das V-Modell gibt standardisierte Vorgehensweisen vor, beschreibt die zugehörigen Ergebnisse und die verantwortlichen Rollen. Damit erhöht das V-Modell die Projekttransparenz und verbessert die Planbarkeit von Projekten. Planungsabweichungen und Risiken werden bereits frühzeitig erkannt. Prozesse lassen sich besser steuern, und das Projektrisiko wird eingedämmt. x Verbesserung und Gewährleistung der Qualität Als standardisiertes Vorgehensmodell stellt das V-Modell sicher, dass die zu liefernden Ergebnisse vollständig und von gewünschter Qualität sind. Die durch das Modell definierten Zwischenergebnisse können auf diese Weise frühzeitig überprüft werden. Außerdem vereinheitlicht das V-Modell die Produktinhalte. Die Ergebnisse sind deshalb besser lesbar, verständlicher und leichter zu überprüfen. Wichtig für den Punkt Risikomanagement ist insbesondere Teil 7 der V-Modell-Referenz Konventionsabbildungen.198 Als wesentliche Basis organisationsweiter Entwicklungsprozesse sollte das V-Modell-XT kompatibel mit aktuellen (Quasi-) Standards, Normen und Vorschriften sein, wie zum Beispiel zur ISO 9001:2000, zur ISO/IEC 15288 und zum CMMI-Modell. Für jede dieser Konventionen enthält die V-Modell-Referenz Konventionsabbildungen eine Abbildung der Begriffe aus der entsprechenden Konvention in die Begriffswelt des V-Modells. Im Projektverlauf müssen der Projektfortschritt und die Projektrisiken kontinuierlich und systematisch überprüft werden und auf Schwierigkeiten entsprechend steuernd zu reagieren. Der Vorgehensbaustein Projektmanagement legt die hierfür notwendigen Verfahren fest. Auf übergeordneter Ebene wird mit Hilfe der Entscheidungspunkte der Projektfortschritt überwacht und das Ge 198

V-Modell-XT, www.kbst.bund.de.

320

10 Schlüsselfaktor Risikomanagement

Abb. 10.1. Die V-Modell-XT Vorgehensbausteine199

samtrisiko für den Projekterfolg entsprechend reduziert. Die Entscheidungspunkte markieren dabei Qualitätsmesspunkte (engl. Quality Gates) zur Entscheidung über den Projektfortschritt und die weitere Projektdurchführung auf Basis der im Entscheidungspunkt vorzulegenden Produkte. Diese Entscheidung liegt in der Verantwortung des Projektmanagers und wird im Rahmen des Lenkungsausschusses, dem alle Schlüsselpersonen des Projektes angehören, getroffen, wie Abb. 10.1 illustriert. Die Entscheidung wird im Produkt Projektfortschrittsentscheidung dokumentiert. Hier werden das Budget und die Ressourcen für den nächsten Projektabschnitt freigegeben. Es können auch Auflagen für den nächsten Abschnitt des Projektes formuliert werden. Sollte die Entscheidung über den Projektfortschritt negativ ausfallen, kann im Einzelfall festgelegt werden, ob der Entscheidungspunkt nach Verbesserung erneut vorgelegt, das Projekt grundsätzlich neu aufgesetzt oder sogar ganz abgebrochen wird. Die konsequente Anwendung der Projektdurchführungs-strategie mit den Entscheidungspunkten führt zu einer risikominimierenden Projekt-steuerung. Fehlentwicklungen werden frühzeitig in den Projektfortschrittsstufen erkannt, so dass früh entsprechende Gegenmaßnahmen ergriffen werden können. 

199

V-Modell XT, www.kbst.bund.de.

10.3 Risikomanagement

321

Abb. 10.2. Kompass der Sicherheitsstandards200

10.3 Risikomanagement vor dem Hintergrund der fehlenden internationalen Zertifikate und Standards für Compliance Zertifikate zur Compliance werden heute nahezu für sämtliche nationalen und internationalen Vorschriften erteilt. Die Zertifizierungen erfolgen jedoch durch unterschiedlichste Zertifizierungsorganisationen und nach sehr unterschiedli 200

BITCOM, a.a.O.

322

10 Schlüsselfaktor Risikomanagement

chen Konzepten. Gemein ist jedoch allen Zertifikaten und Zertifizierungen, dass sie jeweils lediglich Teilaspekte begutachten. Es gibt kein Zertifikat, weder für eine Software- und Hardwaresystem oder eine Infrastruktur, die sämtliche dargestellten Vorschriften erfüllt (siehe Abb. 10.2). So werden Produktzertifizierungen von Buchhaltungs-, Rechnungslegungs- und Dokumentenmanagementsystemen (Soft- und Hardware) auf Compliance zu den Anforderungen des HGB, der GoB und der GoBS gemäß Prüfstandard PS 880 des Institut der Wirtschaftsprüfer (DIW) durchgeführt. Die zu dokumentierenden Verfahren werden durch Verfahrensprüfungen der jeweils überwachenden Behörden (BaFin, Bundesversicherungsamt, SEC usw.) zertifiziert.

11 ILM vor dem Hintergrund der sich abzeichnenden Trends im globalen Wettbewerb und in der Informationstechnologie

11.1 Herausforderung: Business Alignment Häufig werden Verantwortliche der IT-Abteilung mit Kritik aus den Fachbereichen des eigenen Unternehmens konfrontiert: „Sie wissen nicht, was wir wollen und wir können so nicht arbeiten.“ Die Computerspezialisten ihrerseits kontern damit, dass sie den Bereichen die neueste Technik zur Verfügung stellen, diese aber nicht richtig genutzt wird. Dass die in den verwendeten Computersystemen umgesetzten Geschäftsvorfälle oftmals nicht den aktuellen und damit den tatsächlichen Arbeitsabläufen eines Unternehmens entsprechen, stellt ein entscheidendes Problem in vielen Firmen dar. Das so genannte Business Alignment fehlt, d. h. die vorausschauende Abstimmung der Geschäftsprozesse mit den ITSystemen und den Serviceprozessen. Dadurch ist die Abbildung der Wirklichkeit fehlerhaft und somit auch die Verwendbarkeit der Daten stark eingeschränkt. Eine mögliche Ursache dafür kann eine fehlende Harmonisierung verschiedener IT-Systeme, die fehlende Konsolidierung oder gar die übereilte Systemeinführung, getrieben von der Sorge um explodierende Projektkosten und Ressourcenknappheit der letzten Jahre sein. Falsch verstandener Zwang zur Verwendung von Standardsystemen, -prozessen und -datenmodellen sowie übereilter Übergang in den Produktionsbetrieb sind zudem häufige Einführungsfehler. Ändert sich das eigentliche Unternehmensgeschäft, führt dies auch zu Änderungen der Prozesse und Verfahren. Komplexe IT-Systeme und die darauf aufbauenden unstrukturierten Services erschweren die Verwaltung und Wartung der IT. Letztlich verlieren die Unternehmen durch ein fehlendes ILM deutlich an Umsatz, da sich die im globalen Wettbewerb so wichtige Größe „time-to- market“ signifikant verlängerte. Die Auswirkungen beschreibt das Beispiel Airbus Industrie mit ihrem Produkt A380 in eindrucksvoller Weise. Die Entwicklungskosten für den A380 sind mittlerweile auf ca. 12 Mrd. Euro gestiegen. Um so viel Geld zu verdienen, müssten Airbus-Manager nach Schätzung von Branchenkennern rund 400 der Jets verkaufen. Doch so lange nicht geklärt ist, wann die Probleme mit der Verkabelung und andere technische Schwierigkeiten gelöst sind, ist mit den notwendigen neuen Aufträgen kaum zu

324

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

rechnen. Die Verluste belaufen sich nach Expertenschätzung bereits auf 4,8 Mrd. Euro. Unzweifelhaft haben die Schwierigkeiten mit der Verkabelung des A380 – also die Ursache für die zuletzt eingeräumten Lieferverzögerungen – in Hamburg ihren Ursprung. „Im Juni war der Arbeitsaufwand beim abschließenden Einbau der Kabelbäume in die vordere und hintere Rumpfsektion unterschätzt worden“, hieß es in einer offiziellen Erklärung von Airbus am 3. Oktober.201 Die genannten Rumpfsektionen werden auf Finkenwerder produziert. Bei der Montage der Verkabelung sei es zu „verschiedenen Problemen“ gekommen. So sei etwa nicht genug Einbauraum für die Verlegung vorhanden gewesen. Zu diesen Pannen konnte es kommen, weil in Hamburg ein anderes Computerprogramm für die Konstruktion der Elektrik genutzt wurde als in Toulouse. Noch bis vor gut fünf Jahren bestand Airbus aus vier unterschiedlichen Unternehmen in vier Ländern mit sehr unterschiedlichen IT-Systemen. Die Unternehmen benutzten natürlich auch für die Planung des A380 unterschiedliche Computersysteme, glaubten aber, diese untereinander kompatibel machen zu können. Das hat wohl nicht funktioniert! Erst im Juli 2006 wurde demnach entschieden, auch in Hamburg ein bereits in Toulouse verwendetes Programm einzusetzen, mit dem man den Einbau der Kabel vorher dreidimensional simulieren und daher Schwierigkeiten bei der realen Montage vermeiden kann. Die Schulung der Beschäftigten, die damit arbeiten sollen, erfolgt in Toulouse. „Es wird aber ungefähr zwei Jahre dauern, bis alle Kollegen darauf geschult sind“, so der Firmensprecher.202 Schon im vergangenen Jahr hatten die rund 500 Kilometer Kabel, die in jedem einzelnen A380 stecken, für Verzögerungen des Projekts gesorgt. Damals hieß es, man habe den Zeitaufwand unterschätzt, der durch großzügige Berücksichtigung von Sonderwünschen der Kunden für die Flugzeugkabine entstand. Ändert sich zum Beispiel die Position von Einbauten in der Kabine, dann muss auch die Verkabelung entsprechend geändert werden, da jeder der mehr als 500 Passagiersitze mit dem hochkomplexen Bordunterhaltungssystem verbunden ist. Trotz eines Entwicklungsbudgets von nun rund 12 Mrd. Euro und einem ersten größeren Rückschlag vor einem Jahr war es scheinbar nicht möglich, die notwendige IT-Infrastruktur gemäß den Anforderungen des Geschäftsprozesses „in time“ bereitzustellen. Airbus verhält sich hier wie viele Unternehmen. Sie verwenden rund 70 Prozent ihrer IT-Budgets für die Pflege ihrer bestehenden IT-Infrastruktur. Das belegt eine Studie der Meta Group.203 Aktuell soll dieser Anteil sogar auf 80 Prozent steigen. Dadurch stehen immer weniger Mittel für Investitionen in neue Technologien zur Verfügung. Andererseits werden meist nur 20 bis 40 Prozent der verfügbaren Rechen- und Speicherkapazitäten tatsächlich genutzt.204 Auf dem Weg zu ILM ändert sich jedoch nicht nur die IT. Auch die Betriebsführung muss sich weiterentwickeln. Die Tendenz geht hier weg vom herkömmlichen Ressourcenmanagement hin zum Service- und Businessmanagement. Während 

201 202 203 204

Airbus Industrie, Pressemitteilung, www.airbus.com. Airbus Industrie, Pressemeldung, a.a.O. Meta Group, www.metagroup.com. 2 EMC , a.a.O.

11.2 Herausforderung: IT-Sicherheit bei globaler Präsenz

325

das Ressourcenmanagement einen sicheren IT-Betrieb gewährleistet und IT-Services sicherstellt, steuert das Servicemanagement die IT-Prioritäten durch SLAs und verbessert deren Qualität durch den Einsatz von ITIL-basierten „Best Practices“. Das Businessmanagement integriert auf Basis einer Service-orientiertenArchitektur (SOA) schließlich die IT vollständig mit den Geschäftsprozessen. So werden beispielsweise Abhängigkeiten zwischen Geschäftsprozessen und IT-Ressourcen abgebildet und bei Veränderungen in der IT die Auswirkungen auf das Geschäft analysiert. Konsolidierte und standardisierte Infrastrukturen erleichtern nicht nur die Virtualisierung. Unternehmen profitieren auch von einer einfacheren Administration. Anstatt mit zahlreichen unterschiedlichen Software-Tools die Insellösungen zu verwalten, können sie nun die gesamte IT unter einer Oberfläche administrieren. Das so genannte Unified Infrastructure Management (UIM) führt dabei nicht nur die Verwaltung der Server oder nur der Speicherlösungen zusammen, sondern vereint beide in einer umfassenden Ansicht. Offene Schnittstellen erlauben darüber hinaus die Anbindung der Hardwareverwaltung an weiter reichende Managementlösungen. Die Konsolidierung und Standardisierung ihrer Infrastrukturen eröffnet vielen Betrieben einen bislang nicht erreichbaren Grad an Virtualisierung und somit den leistungsfähigeren Betrieb ihrer IT. Generell geht der Blick der IT-Verantwortlichen weg von der isolierten Betrachtung der Infrastruktur hin zu einem Management der gesamten IT-gestützten Unternehmensabläufe. Flexibilität und Skalierbarkeit sorgen hier für eine bislang nicht gekannte Agilität der IT. Unternehmen können durch sie schneller als bisher auf veränderte Geschäftsanforderungen reagieren. Das Ergebnis ist, dass sich die IT nach den Geschäftsprozessen richtet und nicht umgekehrt.

11.2 Herausforderung: IT-Sicherheit bei globaler Präsenz Effizienz und IT-Sicherheit in einer heterogenen IT-Landschaft, die in fast jedem der möglichen mehr als 190 Staaten, in denen ein Unternehmen tätig sein kann, ein anderes Computersystem nutzt, ist unmöglich. Erst ein weitestgehend homogenes Netzwerk in Verbindung mit Konsolidierung und homogenisierter Infrastruktur schafft die Grundlage für die IT-Sicherheit. Nicht nur Einbrüche von außen stellen jedoch ein Risiko dar. Derzeitige Sicherheitslösungen in Form einer Firewall können das Problem eines Datenmissbrauchs oder Datendiebstahls von innen heraus nicht wirklich lösen; sie zeigt nur, wie schwach und verletzbar die derzeitigen Computersysteme und -netze wirklich sind. Mehrere Studien belegen, dass die meisten Unternehmen autorisierte, nicht autorisierte und ehemalige Mitarbeiter als Hauptverdächtige für das Begehen von Informationsverbrechen betrachten. Herkömmliche Serversysteme bergen ein systemimmanentes Risiko in sich. Um die bestehenden Serversysteme verwalten zu können, müssen die Mitarbeiter, die administrative Aufgaben zu erledigen

326

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Abb. 11.1. Die internen Gefahrenquellen205

haben, einen Zugang zu ihnen erhalten. Eine solche „autorisierte“ Hintertür ermöglicht es Systemverwaltern und nicht autorisierten aber kenntnisreichen Benutzern die vertraulichen Daten auszuspähen. Da die Kontrolle der Zugriffssteuerung für Administratoren eine auszuübende Sicherheitsfunktion darstellt, müssen Unternehmen den Systemverwaltern einerseits bedenkenlos vertrauen können, andererseits befinden sie sich in Bezug auf die gesetzlichen Anforderungen des Datenschutzes oftmals zumindest in einer rechtlichen Grauzone. Zusätzlich steht der CIO für global agierende Unternehmen unter dem Zwang, eine fast unüberschaubare Anzahl rechtlicher und normativer Vorgaben zu erfüllen. Selbst Experten können dabei die Übersicht verlieren. Die Verbesserung der Abstimmung von IT und Unternehmensgeschäft in Form des „Strategic Business IT Alignment Models“ (SAM) ist dabei zwingende Voraussetzung. Dieses Modell bestimmt das zwingend notwendige Zusammenspiel zwischen Geschäftsstrategie, -strukturen und -prozessen sowie der IT-Strategie und deren Ausgestaltung im Detail innerhalb der zwei Dimensionen: „funktionale Integration“ und „strategischer Fit“. Eine adäquate Absicherung der unternehmensinternen IT-Infrastruktur muss heute mehr denn je oberste Priorität haben. Alles dies verspricht die Einführung und die Nutzung von Tools für das Management der IT-Infrastruktur. Das Management der Infrastruktur (Server, Speicher und Netze) gehört gleichwohl zu den Kernfähigkeiten im Rahmen eines ILM-Konzeptes. 

205

Price Waterhouse, www.pwcglobal.com.

11.3 Antwort: Nutzung von IT-System- und IT-Netzmanagement

327

11.3 Antwort: Nutzung von IT-Systemund IT-Netzmanagement Systemmanagement befasst sich in erster Linie mit dem Management verteilter IT-Systeme. Hierzu gehören beispielsweise eine zentrale Verwaltung der Benutzer, Softwareverteilung, Management der Anwendungen usw. In einigen Bereichen, wie z. B. dem Konfigurationsmanagement (dem Überwachen und Konsolidieren von Konfigurationen eines Systems oder einer Netzkomponente), sind Netz- und Systemmanagement nicht klar zu trennen. Die Marktführer sind hier HP mit HP Open-View, IBM mit Tivoli und Microsoft mit MOM. Aus Sicht von ILM bestehen hier keine spezifischen Anforderungen. Netzmanagement umfasst die Gesamtheit der Vorkehrungen und Aktivitäten zur Sicherstellung des effektiven Einsatzes eines Netzes. Hierzu gehören beispielsweise die Überwachung der Netzkomponenten auf ihre korrekte Funktion, das Monitoring der Netzperformance und die zentrale Konfiguration der Netzkomponenten. Netzmanagement ist in erster Linie eine organisatorische Problemstellung, deren Lösung lediglich mit technischen Mitteln, einem Netzmanagementsystem, unterstützt werden kann. Aus Sicht von ILM bestehen hier keine spezifischen Anforderungen. Die Frage der Schließung vorhandener oder potenzieller Sicherheitslücken im IT-Infrastrukturmanagement ist beim Betrieb von zentraler Bedeutung. Für den IT-Grundschutz eines Managementsystems werden die typischen Gefährdungen angenommen. Das zu verwaltende System besteht aus einzelnen Rechnern, Netzkoppelelementen und dem physikalischen Netz. Jede dieser Komponenten ist ein potenzielles Sicherheitsrisiko für das Gesamtsystem. Diese Risiken können im Allgemeinen alleine durch die Einführung von Managementsoftware nicht vollständig beseitigt werden. Dies gilt schon deshalb, weil in der Regel nicht alle Systeme in gleichem Maße durch ein Managementsystem erfasst werden. Grundvoraussetzung für die Systemsicherheit ist hier einerseits die Definition und andererseits die Realisierung einer organisationsweiten Sicherheitsrichtlinie, die sich im betrachteten Fall insbesondere in der Konfiguration von Hard- und Software niederschlagen muss. Da Managementsysteme von einem zentralistischen Ansatz ausgehen, kommt der zentralen Managementstation eine besondere Bedeutung unter Sicherheitsgesichtspunkten zu und ist daher besonders zu schützen. Zentrale Komponenten eines Managementsystems sollten daher in Räumen aufgestellt werden, die den Anforderungen an einen Serverraum entsprechen.

11.3.1 BSI Auf Basis des BSI-IT-Grundschutzmaßnahmenkatalogs sind folgende Aktivitäten durchzuführen:206  206

BSI IT-Grundschutzmaßnahmenkatalog, a.a.O.

328

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

11.3.1.1 Berechtigungsverwaltung für Benutzerkonten und Systemkommandos Die Berechtigungsverwaltung kann je nach Hersteller auf unterschiedlichen Ebenen und mit unterschiedlichen Graden der Granularität erfolgen. Bei der Berechtigungsverwaltung von Systemkommandos können Kommandos, die nur bestimmten Nutzern oder Gruppen zugänglich sein sollen, in einer Berechtigungsstufe zusammengefasst bzw. dieser zugeordnet werden. Dies ist beispielsweise vom Hersteller Cisco bereits für zwei Stufen vorkonfiguriert: 1. Die Zuordnung von Systemkommandos zu Berechtigungsstufen, 2. Die Zuordnung von Benutzerkonten zu Berechtigungsstufen.

11.3.1.2 Zugriff auf eine Berechtigungsstufe nur durch ein Passwort abgesichert Ein Nutzer muss für den Zugriff auf ein entsprechend abgesichertes Systemkommando zunächst in die Berechtigungsstufe wechseln und das zugehörige Passwort eingeben. Dann ist er in der Lage, alle dieser Stufe zugeordneten Kommandos auszuführen. Die Berechtigungsvergabe für Benutzerkonten erfolgt, indem der Nutzer einer Berechtigungsstufe zugeordnet wird. Generell sollte gelten, dass jedem Nutzer nur die minimal notwendigen Berechtigungen zugeteilt werden. Somit lassen sich analog der folgenden Beispiele unterschiedliche Rollen definieren. Ein Benutzer ist somit nach seiner Anmeldung am Gerät automatisch einer Berechtigungsstufe zugeordnet, alternativ muss er nach der Anmeldung dediziert die zu nutzende Berechtigungsstufe und das zugehörige Passwort eingeben. Für sicherheitskritische Rollen sollte stets eine Absicherung des Zugriffs über einen zentralen Authentisierungsserver eingerichtet werden. Die Möglichkeiten der Zuordnung von Berechtigungen zu Benutzern und Rollen können sogar so weit gehen, dass für jeden einzelnen Befehl Berechtigungen vergeben werden können, die jedes Mal vor der Ausführung über den Autorisierungsserver überprüft werden. Bei der Erstellung des Rechte- und Rollenkonzepts für die Administration der aktiven Netzkomponenten müssen die Möglichkeiten der einzelnen Systeme in Betracht gezogen werden. Wie fein die Berechtigungsstufen im Einzelfall unterschieden werden, sollte unter Berücksichtigung von Einsatzzweck und Schutzbedarf festgelegt werden. Als Faustregel kann dabei gelten: So fein wie nötig, so einfach wie möglich. Zu grobe Unterteilungen bieten keine angemessene Sicherheit, andererseits können zu feine Unterteilungen die Effizienz der Arbeit beeinträchtigen und bringen die Gefahr von Fehlern mit sich.

11.3.1.3 Passwortverschlüsselung Router und Switches sollten die Möglichkeit unterstützen, Passwörter verschlüsselt in Konfigurationsdateien abzulegen. Beispielsweise kann dies bei Cisco-Geräten mit dem Befehl „enable secret“ erreicht werden. Die Verschlüsselung von Passwörtern ist insbesondere dann wichtig, wenn Konfigurationsdateien über

11.3 Antwort: Nutzung von IT-System- und IT-Netzmanagement

329

das Netz übertragen oder in zentralen Servern gespeichert werden. Wenn die Passwortverschlüsselung unterstützt wird, sollte diese Funktion unbedingt genutzt werden. Dabei sollte das Verschlüsselungsverfahren beachtet werden, da einige Geräte unterschiedliche Verfahren unterstützen. Insbesondere bei älteren Betriebssystemen werden noch schwache Verschlüsselungsverfahren angewendet, die eventuell aus Gründen der Kompatibilität auch in neueren Versionen noch unterstützt werden. Hier sollte bei einer Migration auf ein neues Gerät oder eine neue Betriebssystemversion geprüft werden, ob die neuere Version stärkere Verschlüsselungsverfahren unterstützt. Zudem bestehen für alle Geräte Prozeduren, die es zwar nicht ermöglichen, verschlüsselte Passwörter wieder lesbar zu machen, die aber das Rücksetzen von Passwörtern durchführen. Einige Dienste können nicht durch eine Passwortverschlüsselung abgesichert werden. Hierzu gehören SNMPv1 und SNMPv2, RADIUS und TACACS. Die Passwörter der letztgenannten Dienste sollten somit immer einmalig sein, für keinen weiteren Dienst verwendet und regelmäßig geändert werden. SNMPv1 und SNMPv2 sollten allenfalls in Verbindung mit einem „Out-of-Band“-Management genutzt werden und möglichst kurzfristig durch SNMPv3 ersetzt werden.

11.3.2 Session-Timeouts Sämtliche Zugriffsarten können durch die Vergabe von Passwörtern geschützt werden. Diese Absicherung kann jedoch wirkungslos werden, wenn Sessions unbeaufsichtigt sind, beispielsweise wenn ein angemeldeter Administrator seinen Rechner verlässt und dabei vergisst, die Session zu beenden oder die Bildschirmsperre zu aktivieren. Aus diesem Grund ist es empfehlenswert, Timeouts einzurichten, um Verbindungen nach einem definierten Zeitraum ohne Nutzeraktivität zu beenden oder zu sperren. Dabei sollte eine Timeout-Zeit von 10 Minuten nicht überschritten werden.

11.3.3 Empfehlungen Basierend auf den mehrjährigen einschlägigen Erfahrungen der beiden Autoren bei der Auswahl, der Einführung und dem Betrieb von Infrastrukturmanagement-Tools (IMT) sollte deren Auswahl aus Sicherheitsaspekten u. a. auf Basis der folgenden sechs Fragen erfolgen: x Welcher Typ von „Authentifikation“ wird untersützt? x Welcher Typ der Verschlüsselung wird für die Kommunikation der Systemkomponenten genutzt? x Wo werden die Verschlüsselungen gespeichert und wie gesichert? x Wie werden die vertraulichen Daten (z. B. Passwörter) geschützt während der Speicherung? x Welcher Typ der Zugriffskontrolle wird unterstützt? x Wird die Dokumentation der Events umfassend und sicher durchgeführt (externes Event-Logging)?

330

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Insbesondere alle signifikanten Speichermanagement-Events müssen mit folgenden Ausprägungen gespeichert werden: x Logfiledaten werden gesammelt. x Logfiledaten werden gehalten und anschließend archiviert. x Systemzeiten werden nur mit einer zuverlässigen, externen Quelle sychronisiert.

11.4 Antwort: Nutzung einer Speichermanagementinfrastruktur In den letzten Jahren ist ein signifikanter Fortschritt im Hinblick auf die Verfahren und die Tools zur Verwaltung der Speichersysteme selbst sowie der gesamten Speicherinfrastruktur zu verzeichnen. Wurden in der Vergangenheit der Speichernetzwerke noch für jedes Gerät – ja teilweise sogar für jede Subkomponente – eigene Verwaltungstools benötigt, so stehen aktuell eine Reihe von leistungsfähigen Speichermanagement-Tools zur Verfügung. Derzeitiger Marktführer für Speichermanagement-Tools ist EMC2 mit einem Anteil von knapp 30 Prozent. Auf dem zweiten Platz liegt Veritas, das einen Marktanteil von knapp 19 Prozent behauptet. Auch der Drittplatzierte, IBM, hielt im letzten Jahr seinen Marktanteil mit etwas mehr als zwölf Prozent fast unverändert. Ziel des Einsatzes von Speichermanagement-Tools ist es, in Speichernetzwerken eine verbesserte Skalierbarkeit und eine bessere durchschnittliche Auslastung der Gesamtkapazität zu erreichen. Von Effizienz kann häufig bei Auslastungsquoten zwischen 40 und 60 Prozent keine Rede sein. Die Antwort Virtualisierung hebt durch eine zusätzliche Schicht sowie durch einen Mechanismus, der steuernd eingreift, die Grenzen einzelner Speichersysteme auf. Der IT-Manager kann Pools bilden, Daten unbemerkt von deren übergeordneten Anwendungen hin- und herschieben oder zur Sicherheit klonen, das alles von einem zentralen Ansteuerungspunkt aus. Doch blieb bisher der durchschlagende Erfolg aus. Die Virtualisierungstechnik hat noch mit Zweifeln hinsichtlich Leistungsfähigkeit, Stabilität und Skalierbarkeit zu kämpfen. Andererseits gibt es mittlerweile viele zufriedene Unternehmen, die die Funktionen, die sonst teuren Systemen vorbehalten waren, intensiv nutzen und die vereinfachte Administration zu schätzen wissen. Die Qualität des Managements von Speicherumgebungen muss sich auch und vor allem daran messen lassen, wie effizient Daten in der Umgebung abzulegen sind. Diese Effizienz ist vom Wert der Informationen abzuleiten, die in den Daten enthalten sind. Sind Informationen wichtig, weil sie neu sind und ein häufiger Zugriff zu erwarten ist, so wäre eine Lagerung auf zu langsamen Systemen geschäftsschädigend, da alle mit diesen Informationen zusammenhängenden Tätigkeiten verzögert würden. Das heißt, es werden Prozesse verlangsamt, was im Extremfall unter anderem zu einer Verminderung von Produktion führt. Neben den technischen Parametern ist wichtig, Basiswerte für die Informationen

11.5 Antwort: Nutzung von Security Management Tool

331

zu definieren und in der Organisation bestimmten Positionen, Verteilergruppen oder logischen Zusammenhängen zuzuweisen. Die Management-Tools ermöglichen zentralisiertes Management von Speicherressourcen in verteilten und Mainframe-Umgebungen. Die Lösung bietet Analyse, Management, Reporting sowie Terminplanung als zentralisierte Funktionen und automatisiert unternehmensweit netzwerkgestützte Speicherressourcen. Erst umfangreicher Support für die führenden Applikationen, Datenbanken, Betriebssysteme und Hardware macht ein vollständiges End-to-End-Ressourcenmanagement möglich. BrightStor SRM liefert eine zentralisierte Sichtweise über die Verfügbarkeit und die Nutzung von Speicherressourcen mit dem Ziel, die Planung, die Zuweisung und die Auslastung von Speicherkapazitäten deutlich zu verbessern. Die führenden Anbieter von Speicher- und Speichermanagement wie EMC, HewlettPackard (HP), Hitachi, Sun Mirosystems und Symantec wollen gemeinsam in der „Storage Management Initiative Specification“ (SMI-S) einen Industriestandard für die Verwaltung von Disk Arrays und Speicher-Switches entwickeln. Obwohl in der Storage Networking Industry Association (SNIA) als auch in der SMI-S-Industrievereinigung bezogen auf den Marktanteil die größeren Speichersystemanbieter beteiligt sind, fehlt mit IBM einer der wichtigen „Full Scale Global Player“. IBM verfolgt auch bei der Speicherstandardisierung ein Open Source Modell. Die Einhaltung des SMI-S-Standards wird durch die SNIA kontrolliert. Sie regelt derzeit die Programmierung einer beschränkten Anzahl von Services für Speichermanagementsoftware, darunter die Bereiche Discovery, Management und Reporting im Hardware Data Center. Künftig wollen die Anbieter mit SMI-S nun auch die Themen Workflow, Security, Dependency Management, Reporting Construct und Policy Enforcement standardisieren. Zudem will die Industriegruppe eine Reihe von APIs (Application Programming Interfaces) entwickeln, um Software mit Hardware zu verbinden. Sobald die Spezifikation fertig gestellt ist, soll eine Referenzimplementierung gebaut werden. Ein Zeitplan dafür steht aber aktuell noch nicht fest.

11.5 Antwort: Nutzung von Security Management Tool BSI, SNIA und die eigenen Erfahrungen zeigen, dass ein funktionierendes Sicherheitskonzept zu mindestens 80 Prozent auf einer durchgängigen Organisation und einer konsequenten Betriebsführung beruht. Die Kernaufgabe der Betriebs- und IT-Sicherheitsorganisation ist es, aufsetzend auf den Internationalen Standards ISO 17799 und ISO 20000 die Integration der für ILM relevanten Vorgaben sowie weiterer einschlägiger Vorgaben zu bewerkstelligen. Weitere Anforderungen an die Betriebs- und IT-Sicherheitsorganisation, die über den in Kap. 10.3 vorgestellten Kompass hinausgehen, sind z. B.: x Technische Standards von EDIFACT usw. x Codes of conduct herausgegeben durch EU, OECD, ISACA usw.

332

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

x Qualifikationskriterien für IT-Systeme und -Prozesse: ITSEC, TCSEC, SPICE, TickIT, Common Criteria usw. x Berufsstandards in der internen Kontrolle und Revision: COSO Report, IFAC, AICPA, IIA, ISACA, PCIE, GAO Standards usw. x Industriepraktiken und Anforderungen von Industriegremien (ESF, I4) sowie staatlich gesponserten Plattformen (IBAG, NIST, DTI) usw. Damit wird klar, dass auch im Bereich der Betriebs- und IT-Sicherheitsorganisation eine Vielzahl sehr unterschiedlicher Anforderungen zu erfüllen sind, die letztlich dazu führen, dass in der praktischen Umsetzung alle Verantwortlichen überfordert sind. Wichtig für ILM ist, dass Informationssicherheit einsetzbar gestaltet wird. Die Eckpfeiler sind dabei: x ISO 17799 (IT-Sicherheit), x ISO 20000 (Betriebsorganisation), x ISO 27001 (IT-Sicherheitsorganisation). Die beiden Autoren müssen in diesem Zusammenhang auf die fast unüberschaubare Literatur zum Thema Organisationen und deren Aufbau verweisen. Der Aufbau einer Organisation ist meist etwas sehr unternehmensspezifisches. Gleichwohl stellen sich generell die folgenden Aufgaben für jede Organisation mit dem Schwerpunkt IT-Sicherheit: x x x x x x x x x x x

Weisungen und Richtlinien zur Informationssicherheit, Organisatorische Sicherheitsmaßnahmen und Managementprozess, Verantwortung und Klassifizierung von Informationswerten, Personelle Sicherheit, Physische Sicherheit und öffentliche Versorgungsdienste, Netzwerk- und Betriebssicherheit (Daten und Telefonie), Zugriffskontrolle, Systementwicklung und Wartung, Umgang mit Sicherheitsvorfällen, Business Continuity Management – Notfallvorsorgeplanung, Compliance – Einhaltung rechtlicher Vorgaben, der Sicherheitsrichtlinen und Überprüfungen durch Audits.

Hauptziel der Informationssicherheit ist es, die wichtigen mittelbar und unmittelbar wertschöpfenden Prozesse gemäß ihrem spezifischen Schutzbedarf zu schützen. Maßgeblich sind dabei die Faktoren Infrastruktur, Architektur, Betriebsorganisation sowie insbesondere die Mitarbeiter. Informationssicherheit will Informationen in allen Varianten angemessen schützen. Bereits hier ist erkennbar, dass es nicht das Ziel ist, Informationen grundsätzlich maximal zu schützen. Hier greift die Thematik des Schutzbedarfs von Informationen bzw. einer Risikoanalyse. ISO 17799 und ISO 20000 in Verbindung mit ISO 27001 unterstützen die Verwendung eines prozessorientierten Ansatzes für Einführung, Implementierung, Betrieb, Überwachung, Wartung und Verbesserung der Effektivität des Information Security Management Systems (ISMS) in einer Organisation.

11.5 Antwort: Nutzung von Security Management Tool

333

Im Bereich der technischen Sicherheitsmaßnahmen lässt sich ISO/IEC 17799 sinnvoll durch das IT-Grundschutzhandbuch des Bundesamts für Sicherheit in der Informationstechnik ergänzen. Aus Teil 2 von BS7799 hat sich der ISO/IECStandard 27001:2005 entwickelt. Er spezifiziert die Anforderungen an ein Information Security Management System (ISMS) und ist vergleichbar zu ISO 9001, dem vorgestellten Managementstandard für die Qualitätssicherung. Die ISO/IEC-Standards zur Informationssicherheit sollen sukzessive erweitert werden. Die vier weiteren Standards der ISO 27000-er Reihe sind bereits in Entwicklung, weitere in Planung.

11.5.1 Information Security Management Software (ISMS) Indem die eingesetzten IT-Sicherheitsinformation- und Event-ManagementLösungen die Sicherheitsprozesse automatisieren, vereinfachen und rationalisieren, können die unternehmensinternen Sicherheitsmaßnahmen auf die Geschäftsanforderungen eines Unternehmens abgestellt werden. Eine Echtzeitsicht auf die täglichen Sicherheitsereignisse ist gewährleistet. Indem diese beiden Anforderungen miteinander verbunden und dabei Sicherheitsinformationen intelligent priorisiert wurden, sorgt ISMS dafür, dass Gefahren für die IT, das Unternehmen und für Dritte sofort erkannt werden. Laut einer aktuellen Gartner-Studie wuchs der gesamte Markt für Software und Applikationen im Bereich Security Information und Event Management 2005 um 32,2 Prozent auf über 288 Mio. US $. Zwar sind, so die Gartner-Studie, in den vergangenen Jahren die IT-Budgets geschrumpft, aber in Markt für Produkte im Bereich IT-Sicherheitsinformationssysteme und Event Management wird weiterhin investiert.207 Diesen Lösungen kommen bei der Kontrolle und dem Reporting von Compliance-Maßnahmen und dem wachsenden Bedarf an Threat Monitoring und Incident Response eine zunehmende Bedeutung zu. Eine wichtige Rolle bei der übergreifenden Überwachung und Steuerung aller Sicherheits-Tools in den Unternehmen spielt das eTrust Security Command Center. Diese zentrale Managementkonsole hat Gartner in seinen „Leaders Quadrant“ aufgenommen. In magische Quadranten ordnet Gartner die IT-Werkzeuge ein, die auf verschiedene Kriterien geprüft wurden. Im „Leaders Quadrant“ finden sich Produkte, die in Bezug auf Vollständigkeit und Ausführungskompetenz hervorstechen. Die Aufnahme eines ISMS in die Unternehmensorganisation sollte eine strategische Entscheidung sein. Das Design und die Implementierung eines ISMS innerhalb der Organisation werden durch geschäftliche Anforderungen und Ziele bestimmt, ebenso daraus resultierende Sicherheitsanforderungen, die eingesetzten Prozesse und die Struktur der Organisation. Es ist zu erwarten, dass sich diese sowie deren unterstützenden Systeme im Verlauf der Zeit verändern. Einfache Situationen erfordern einfache ISMS-Lösungen. Die Komplexität des Unternehmens soll im ISMS gespiegelt werden. Die Sicherheitskultur muss 

207

Studie Gartner, www.gartner.com.

334

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

als Attribut der Unternehmenskultur gesehen werden. Sicherheitskultur ist ebenfalls Attribut des IT-Sicherheitsmanagements und wird von diesem angetrieben. Weder die Normen noch eine ISMS-Lösung selber formulieren die einzelnen Prozesse aus, sondern sie beschränken sich auf die Formulierung „was“ zu tun ist. Um Mitarbeiter tatsächlich in ihrer täglichen Arbeit zu unterstützen, müssen die einzelnen Prozesse aber ausformuliert werden. Die Mitarbeiter müssen trotz Prozessen noch wissen, was sie tun sollen. Bei der Entwicklung der Prozesse ist davon auszugehen, dass Mitarbeiter gut ausgebildet sind, ihre Arbeit kennen und nur in einzelnen Punkten Unterstützung brauchen. Dieses wird mit einem prozessorientierten Ansatz erreicht. Insbesondere die Entscheidung über Informationsschutz- und Sicherheitsrichtlinien (Security Policy) ist Aufgabe des obersten Managements. Da das Management in der Regel nicht selbst diese Policies ausarbeitet, sollte ein Information Security Officer (Corporate Security Officer, CSO) oder eine Information-Security-Management-Gruppe eingesetzt werden, die für die Formulierung der Security Policies sowie für die Überwachung ihrer Einhaltung innerhalb der Organisation verantwortlich ist. Kulturelle Aspekte sind in der ganzen Unternehmung anzutreffen – diese zu verändern liegt in der Verantwortung des Managements. Diese Kulturveränderung durchzuführen ist Aufgabe der Führungskräfte, forciert und unterstützt durch das Informationssicherheitsmanagement. Heute bekannt sind Sicherheitsmarketing, Sensibilisierungstrainings und interne PR-Maßnahmen. Der umgekehrte Ansatz geht vom Menschen aus und nicht von den Maßnahmen. Jeder Mensch hat eine andere Wahrnehmung. Dies erschwert die Erreichung eines gemeinsamen Nenners erheblich. Die Wahrnehmung der Mitarbeiter basiert auf Werten, Weltbildern, Erfahrungen und Gefühlen. Man kann Informationssicherheit so umsetzen, dass sie niemand leben kann. Und man kann Informationssicherheit messen, auch wenn sie nicht gelebt wird. Das Ziel, Informationen angemessen zu schützen, verlangt ein lebbares Information Security Management System, welches den Mitarbeitern in der täglichen Arbeit ermöglicht, Vorgaben umzusetzen. Die Prozesse für die Informationssicherheit müssen zu diesem Zweck ausformuliert werden. Schwierigste Aufgabe ist danach, Mitarbeiter dazu zu bringen, diese Vorgaben zu leben. Letzteres sollte dringend eine höhere Priorität erhalten. Für das Reporting in einer Informationssicherheitsumgebung ist entscheidend, dass die Wirklichkeit gemessen wird, das Gelebte. Dazu bedienen wir uns entsprechenden Messmethoden wie sie im Open Source Security Testing Methodology Manual (OSSTMM) oder dem Informationssicherheits-Kultur-Radar beschrieben sind. Nur wer diese Ansätze konsequent verfolgt, kommt der gelebten Informationssicherheit einen Schritt näher.

11.5 Antwort: Nutzung von Security Management Tool

335

11.5.2 Outsourcing in Form eines Managed Security Service (MSS) Immer mehr Unternehmen gehen einen anderen Weg und verlagern das Risiko für die operative IT-Sicherheit in Form eines Managed Security Service (MSS) an Dritte. Forrester rechnet im Jahr 2008 allein für Europa mit einem Marktvolumen von 962 Millionen Euro für MSS. Die jährliche Zuwachsrate liegt bei mehr als 30 Prozent. Nach Gartner werden im Jahre 2005 bis zu 60 Prozent aller Unternehmen zumindest Teile des Sicherheits-Monitorings von IT-Netzwerken ausgelagert haben.208 Ein MSS-Provider kann eine Vielzahl von Kosten für spezialisierte IT-Sicherheitsexperten, Hardware und Software sowie für umfangreiche Einrichtungen wie 24-Stunden-Support-Zentren auf mehrere Kunden verteilen. Dies senkt die Kosten pro Arbeitsplatz deutlich. Ein weiteres Argument, das für Outsourcing spricht ist, dass das notwendige qualifizierte Fachpersonal trotz der momentanen Wirtschaftslage nicht leicht zu finden ist. Umso höher der benötigte Spezialisierungsgrad der Experten wird, umso weniger kann sich ein „normales“ Unternehmen diese leisten. Ein Dienstleister, der sich das Thema MSS auf die Fahne schreibt, hat dagegen einen guten Zugang zu IT-Sicherheitsexperten. Dazu kommt, dass die internen Mitarbeiter häufig anfallende Aufgaben neben weiteren Tätigkeiten erledigen müssen. Teilzeit-Security-Fachleute können jedoch nicht in gleichem Maße die Kompetenz aufbauen wie ein Mitarbeiter, der nur für diesen Bereich zuständig ist. Dies macht MSS gerade für kleinere Firmen interessant, die mit weniger Personalressourcen auskommen müssen. Doch selbst für viele große Unternehmen ist es eine Herausforderung, einen 24-Stunden-ITSicherheitsbetrieb mit entsprechender Organisation und Technik aufzubauen und zu betreiben. Häufig wird daher auf die Einführung komplexer MonitoringSysteme und gut ausgestatteter Computer Emergency Response Teams (CERTs) verzichtet. Mit der Hilfe von sehr leistungsfähigen Systemen und CERTs kann ein MSS-Provider in kurzer Zeit auf aktuelle Bedrohungen reagieren und Reports über die IT-Sicherheitslage des Unternehmens liefern. Ein häufiges Problem großer Firmen ist insbesondere die starke Zersplitterung und Heterogenität ihrer technologischen Infrastruktur. Outsourcing kann hier helfen, Standards zu setzen. Schließlich ist ein hochspezialisierter IT-Security-Dienstleister bestens informiert über aktuelle Sicherheitsrisiken und Softwarelösungen. Nutzt der MSSProvider seine IT-Sicherheitssysteme für mehrere Mandanten, führt dieses zu neuen, zusätzlichen Risiken. Die Vertraulichkeit der Kundendaten und -informationen muss gewährleistet sein. Das größte Risiko ist jedoch in der Einführung des Outsourcings selbst zu sehen. Die Fremdvergabe eines Betriebsteils stellt den Kunden beziehungsweise den betroffenen IT-Leiter vor das Problem, eine IT-Organisation gänzlich neu aufzubauen. Die Vorbereitung der Betriebsverlagerung bedarf einer gründlichen Planung und Durchführung. Fehler in den Phasen der Angebotseinholung, Vertragsverhandlungen oder der laufenden  208

Gartner, a.a.O.

336

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Betriebsüberführung sind später kaum korrigierbar. Dazu kommen noch rechtliche Auflagen und Personalfragen, die für viele IT-Leiter ein unbekanntes Neuland darstellen.

11.6 Antwort: Nutzung des SANund NAS-Switch-Managements Im SAN und NAS sind die Switches und Router die zentralen Komponenten der Kommunikation. Zum Stand der Technik gehört die Möglichkeit der RemoteAdministration. Das Switch-Management kann damit einen zentralen Beitrag zur Verbesserung der IT-Sicherheit leisten.

11.6.1 IT-Sicherheitsempfehlungen bei Nutzung von Telnet Die Nutzung von Telnet birgt die Gefahr des Ausspähens von Authentisierungsdaten, da sämtliche Daten im Klartext übertragen werden und somit der Datenverkehr inklusive des Benutzernamens und Passwortes mitgelesen werden kann. Oft wird zur Remote-Administration auch SNMP verwendet. Die Varianten SNMPv1 und SNMPv2 bieten ebenfalls keine ausreichenden Möglichkeiten zur Absicherung der Kommunikation. Erst SNMPv3 unterstützt spezifische Sicherheitsmechanismen, die einen Einsatz auch außerhalb abgeschotteter Administrationsnetze erlauben. Bei Remote-Zugriff auf Router und Switche muss deshalb in jedem Fall eine Absicherung der Kommunikation erfolgen. Dieses lässt sich beispielsweise durch die Nutzung des Dienstes SSH anstatt Telnet oder durch die Schaffung eigener LAN-Segmente erreichen, die ausschließlich für Administrationszwecke genutzt werden. Eine ungesicherte Remote-Administration über externe (unsichere) Netze hinweg darf in keinem Fall erfolgen. Dies muss bereits bei der Festlegung der Sicherheitsrichtlinie berücksichtigt werden. Auch im internen Netz sollten soweit möglich keine unsicheren Protokolle verwendet werden.

11.6.2 IT-Sicherheitsempfehlungen bei Nutzung von Web Service Die Durchführung der Administration kann mit Hilfe des Dienstes HTTP über ein Browser-Interface erfolgen. Sowohl auf dem Router als auch auf dem Switch ist in diesem Fall ein HTTP-Server gestartet, der Zugriff erfolgt von beliebigen Clients über einen Web-Browser. Die Standardeinstellungen für den Zugriff auf das Web-Interface sind nicht bei allen Herstellern einheitlich. Idealerweise sollte der Zugriff in der Grundeinstellung deaktiviert sein, es ist aber auch möglich, dass dieser Dienst standardmäßig ungeschützt ohne Eingabe von Benutzerinformationen verwendet werden kann. Dies ist bei der Inbetriebnahme der Geräte zu prüfen, gegebenenfalls muss die Konfiguration entsprechend geändert

11.6 Antwort: Nutzung des SAN- und NAS-Switch-Managements

337

werden. Wie bei der Nutzung des Dienstes Telnet wird auch beim HTTP der Benutzername und das Passwort im Klartext übertragen. Zudem ist eine Reihe von Exploits bekannt, die Schwachstellen der HTTP-Server der unterschiedlichen Hersteller ausnutzen. Daher wird von der Nutzung des HTTP-Dienstes für Administrationszwecke dringend abgeraten. Der HTTP-Server sollte nach Möglichkeit bei der Erstkonfiguration des Systems deaktiviert werden, sofern der Zugriff nicht über ein gesondertes Managementnetz erfolgt. Manche Hersteller bieten auch die Möglichkeit, über HTTPS auf das Web-Interface zuzugreifen. Sofern eine Web-Administration notwendig ist, sollte, sofern die Möglichkeit besteht, HTTPS in jedem Fall der Vorzug vor HTTP gegeben werden.

11.6.3 IT-Sicherheitsempfehlungen bei Nutzung von VLAN Um den Risiken bei der Remote-Administration entgegenzuwirken, bieten einige Geräte die Möglichkeit, einen eigenen logischen Port (Management-Interface) zur Administration zu konfigurieren. Bei Switches sollte dieser Port einem VLAN zugeordnet werden, welches ausschließlich für administrative Zwecke verwendet wird (Out-of-Band-Management) und dem ausschließlich Management-Interfaces angehören. Das Managementnetz sollte komplett von anderen Teilen des Netzes getrennt werden. Erst dadurch werden Schwachstellen, wie z. B. unverschlüsselt übertragene Anmeldeinformationen, bei den für administrative Aufgaben zur Anwendung kommenden Protokollen wie Telnet oder die veralteten SNMP-Varianten kompensiert. Die Access Control Lists (ACL) sind dabei gemäß den Herstellervorgaben so zu konfigurieren, dass der Zugriff auf das Management-Interface nur der Managementstation erlaubt ist. Alle nicht benötigten Dienste sind für das Managementinterface zu deaktivieren.

11.6.4 IT-Sicherheitsempfehlungen bei Nutzung von zentralen Authentifizierungsserver Statt lokal auf dem Gerät die Zugriffsrechte und deren Kontrolle zu konfigurieren, kann dies auch über einen zentralen Server erfolgen. Bei großen Umgebungen mit einer hohen Anzahl von aktiven Netzkomponenten ist die lokale Konfiguration nur bedingt praktikabel. Der Aufwand für die Administration und für viele parallel zu pflegende Berechtigungen ist dann sehr hoch. Auf dem zentralen Server werden dabei einheitlich alle Zugriffe und Berechtigungen verwaltet. Die sensitiven Daten sind nicht mehr auf den Geräten selbst gespeichert und müssen nicht einzeln gepflegt werden. Stattdessen sind alle Informationen verschlüsselt in einer Datenbank abgelegt und lassen sich übersichtlich verwalten. Ein solcher Server bietet zudem erweiterte Möglichkeiten zur Protokollierung, beispielsweise können Anzahl und Zeitpunkt von Einwahl- oder Zugriffsvorgängen und übertragene Datenmengen dokumentiert werden. Beispiele hierfür sind RADIUS und TACACS+ (Terminal Access Controller Access Control System). Die Authentisierung sollte in komplexen Netzen mit einer Vielzahl von aktiven Netzkomponenten durch einen zentralen Authentisierungsserver abgesichert

338

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

werden. Für den Fall, dass kein Authentisierungsserver genutzt werden kann (beispielsweise beim Ausfall des Servers oder bei Netzproblemen), sollte trotzdem ein lokaler Zugriff konfiguriert sein. Dieser ist durch ein nur für diesen Zweck zu nutzendes Passwort abzusichern. Für lokale Zugänge, die nicht eigens für den Fall eingerichtet wurden, dass der Authentisierungsserver nicht zur Verfügung steht, sollte der Authentisierungsserver nach Möglichkeit genutzt werden, da ansonsten die Benutzer, die sich lokal anmelden, die zentrale Autorisierung und Überwachung umgehen.

11.6.5 Allgemeine IT-Sicherheitsempfehlungen Allgemeine IT-Sicherheitsempfehlungen für Switches: x Nicht benötigte Ports in den Status „Unassigned VLAN“ versetzen oder deaktivieren, x Genaue Uhrzeit auf den Geräten einstellen (interner NTP-Server), x Einbinden der Zeitinformation bei der Protokollierung, x Auswerten, Überprüfen und Archivieren der Protokolldateien entsprechend der Sicherheitsrichtlinie, x Überprüfung der Default-Einstellungen, x Einrichtung eines Login-Banners, x Deaktivierung von CDP auf Endgeräte-Ports, x Bei Nutzung von VTP: Authentisierung verwenden, x Deaktivierung von Trunk-Negotiation auf Endgeräte-Ports, x Deaktivierung von STP (Spanning Tree) auf Endgeräte-Ports und x Festlegung einer Root-Bridge. Spezielle IT-Sicherheitsempfehlungen für die Administration: x SNMP möglichst deaktivieren, Nutzung nur in Verbindung mit Out-of-BandManagement (Administrationsnetz) oder Verwendung von SNMPv3, x Aufbau und Nutzung abgeschotteter Administrationsnetze, x kein „Default-VLAN“ nutzen, x Einrichtung eines eigenen VLAN für alle Trunk-Ports und x Einrichtung eines „Unassigned-VLAN“ für alle unbenutzten Ports.

11.7 Antwort: Nutzung verbesserter Methoden beim SAN-Zoning und beim LUN-Masking Die beschriebenen SAN-typischen Schutzmechanismen SAN-Zoning und LUNMasking bieten in der Form, wie sie heute eingesetzt werden, in der Realität keine umfassende Sicherheit. Per Zoning lassen sich die SAN-Switche einer Fabric in logischen Einheiten zusammenfassen und die Zugriffsrechte auf die verschiedenen Speicher-„Devices“ vergeben. Bezüglich der Datensicherheit ist dieses Verfahren jedoch bedenklich,

11.7 Antwort: Nutzung verbesserter Methoden beim SAN-Zoning und beim LUN-Masking

339

da sich ein Angreifer die Kontrolle über eine Fabric-Port-Adresse verschaffen und sie für Spoofing-Attacken missbrauchen kann. In diesem Fall werden alle Einstellungen für das Hard-Zoning obsolet, also die hardwarebasierte Routing-Begrenzung, und beim Soft-Zoning, die Auflösungsbeschränkung der Simple-NameServer-Adressen. Ohne zusätzliches Tool für die starke Authentisierung lässt sich LUNMasking über das World Wide Name (WWN-) Spoofing aushebeln. So erhält ein Angreifer einen direkten Zugriff auf ein Speicher-„Device“, indem er etwa einen falschen Servernamen verwendet. Ein weiteres Minus ist die Ausrichtung des LUN-Masking auf das Speicher-„Device“ und nicht auf die Daten. Werden sie an einen anderen Speicherort migriert, werden die verhängten Zugangsbeschränkungen wirkungslos. Zwar sind noch keine einschlägigen IT-Sicherheitsvorfälle bekannt, jedoch gilt auch hier die Erfahrung, gibt es einen Weg, so muss damit gerechnet werden, dass er auch genutzt wird. Knackpunkt jedes Sicherheitskonzeptes im SAN ist der Zugang zum SAN. Server können direkt am SAN angeschlossen werden, sie können darauf durch eine IP-Verbindung mit einem Management-Port in einem SAN-Switch zugreifen oder durch ein installiertes FC-IP-Routing-Produkt (iFCP oder FCIP). Im Allgemeinen kann die Sicherung gegen unbefugten Zugang durch HardZoning erreicht werden, das Frame-Forwarding verhindert. Zusätzlich muss beim Entwerfen von SANs darauf geachtet werden, die einzelnen Zonen absolut zu trennen und so jede Kommunikation zu verhindern. Der SAN-Zugang sollte zudem nur auf Basis von „need to connect“ erlaubt werden. Diese konsequente Separierung kann durch die Verwendung von „Private Loop“ (PL-) FC-SANs erreicht werden, wo nur „Locale Loop“ (LL-) Zugang haben, die aber sonst nichts ausführen können. Generell sollten zudem alle Managementports der SAN-Switche nur über Benutzerauthentifizierung ansprechbar sein. Zur Verbesserung der IT-Sicherheit im Bereich SAN-Zoning und LUNMasking sind folgende zusätzliche Maßnahmen anzuraten: Als Protokoll sollten Fibre Channel Generic Services 4 (FC-GS-4) genutzt werden. Im Protokoll FC-GS-4 wird ein Zoning-Verfahren festgeschrieben, das den Austausch innerhalb der Fabric durch eine sogenannte „frame-by-frame“Filterung limitiert. In der Standardkonfiguration der Filterung sind die Zonenparameter so definiert, dass Hard-Zoning nicht unterstützt wird. Es gibt auch beim LUN-Masking in einem SAN unterschiedliche Methoden: Durch „Agenten“ auf den Servern wird der Zugang zu besonderen LUNs für nicht Berechtigte gesperrt. Sicherheitsrisiken bestehen immer dann, wenn ein Agent nicht eingesetzt wird oder schlecht bzw. falsch konfiguriert auf dem Server etabliert wird. In diesem Fall besteht auch hier die Wahrscheinlichkeit eines ungesicherten LUN-Zugangs von jedem eingerichteten Knoten. Bei der zweiten Methode nutzt die Firmware das Array des Switches, um den Host-Access auf partikulare LUN’s durch Nutzung der WWN herzustellen. Das Array hat die Zugangsliste für den Host Access im Non Volatile Random Access Memory (NVRAM) oder im Memory des Switches gespeichert.

340

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Werden bereits bei der Planung obige Grundsätze in Verbindung mit der Regel „no single Point-of-Failure“ berücksichtigt, d. h. insbesondere eine zweipfadige Anbindung und erfolgt eine Umsetzung gemäß den definierten Qualitätsstandards, dann ist ein sicherer Betrieb des SAN nach dem aktuellen Stand des Know-hows gewährleistet. Die eigenen Erfahrungen der beiden Autoren zeigen, dass zudem eine homogene SAN-Infrastruktur (möglichst nur ein Hersteller, möglichst wenige verschiedene Switch-Typen mit einem einheitlichen Firmware- und Patch-Level) unter Umsetzung des generellen Prinzips der zweipfadigen Anbindung auch im großen Umfang stabil ist und nur wenig direkten Support bedarf. Wichtig dabei ist insbesondere, dass durch die Supportfreigabe der Speicher- und der Switch-Hersteller bei Bedarf ein direkter Support sichergestellt ist. Die Supportfreigabe der Hersteller, die bei der SAN-Planung involviert sind, muss demzufolge ein wichtiger Punkt in der QS-Planung sein und darf auf keinen Fall versäumt werden.

11.8 Antwort: Nutzung der Grid- bzw. Virtualisierungstechnologie Die Grid-Technologie ist eine Virtualisierungstechnologie um die Ressourcen unabhängig von Plattform und Ort nach Bedarf zu allozieren. Für rechenintensive Aufgaben wird Grid-Computing genutzt, die eine enorme Rechenpower aus einer virtualisierten und flexiblen Ressourcen-Allozierung heraus bereitstellt. Typischerweise arbeiten Linux-Farmen dafür mit mehreren hundert bis zu mehreren tausend Rechnern. Grid Architekturen finden aber auch immer mehr Verwendung in der Enterprise-IT wie etwa „Oracle Database 10g“ für GridTechnologie im Datenbankumfeld, SAP „Netweaver Adaptive Computing Infrastructure“ oder die Fujitsu Triole-Strategie mit „FlexFrame“ (Grid) für SAPUmgebungen. Grundvoraussetzung für ein Speicher-Grid ist die Möglichkeit, unabhängig von Speichermodell und der Netzwerkinfrastruktur – SAN oder IP – auf den Speicher zugreifen zu können. Die Idealvorstellung ist ein System, das Datenbereiche ohne Partitionierung gleichzeitig für blockorientiert arbeitende Storage Area Networks und für File-basierte I/O über TCP/IP-Netzwerke bereitstellt. Hinzu kommt die Verfügbarkeit üblicher Protokolle wie NFS, CIFS, FibreChannel, iSCSI und HTTP und eine möglichst breite Connectivity mit GigabitEthernet, Fibre-Channel und SCSI. Speicher-Grids müssen auf den in Unternehmen vorhandenen Strukturen aufsetzen. Speichersysteme verschiedener Hersteller und diverse Speicherklassen wie Primärspeicher oder Sekundärspeicher müssen daher ebenso integrierbar sein wie heterogene Strukturen. Ein weiterer Baustein ist das Datenmanagement, das nicht nur eine einheitliche Sicht auf die Speicher-Grid-Struktur bieten sollte, sondern auch Funktionen wie beispielsweise Mirroring, Backup, Snapshots und Disaster Recovery. Aufgrund der übergreifenden, universellen Struktur muss das Speicher-Grid sowohl lokal

11.8 Antwort: Nutzung der Grid- bzw. Virtualisierungstechnologie

341

als auch remote einsetzbar sein. Auf dieser Basis lässt sich ein Speicher-Grid auch als Grundlage für eine ILM- und Compliance-Lösung verwenden. SpeicherGrids können den Anforderungen unterschiedlicher Datenklassen und Speicherklassen Rechnung tragen. Sie sorgen auf einer automatisierbaren Basis dafür, dass Daten mehr oder weniger häufig gesichert oder bei geringer Nutzung auf preisgünstigere Speicher migriert werden. Ein weiterer wesentlicher Baustein des Speicher-Grid ist der Global-NameSpace. Aus Sicht des Nutzers liefert er eine Abstraktionsschicht, die sicherstellt, dass der Nutzer Zugriff auf seine Daten hat, ohne wissen zu müssen, wo sie physikalisch gespeichert sind. Man kann sich diese Art des Datenzugriffs analog zu URLs und dem Zugriff auf Webinformationen vorstellen. Auf welchem Webserver die gewünschten Informationen liegen, ist für den Zugriff völlig irrelevant. Hinter dem Global-Name-Space lassen sich Daten zudem transparent migrieren, ohne den Endanwender zu beeinträchtigen oder davon in Kenntnis zu setzen. Damit werden die Bausteine des Speicher-Grid aus Datensicht zu einem Speichernetz, da die Daten transparent auf die jeweils passende Speicherklasse im Grid verlagert, gespiegelt oder gesichert werden kann. Speicher-Grids erfordern jedoch noch mehr als die bekannte Möglichkeit der verteilten Datenhaltung. Es bedarf vielmehr der zusätzlichen Sicherstellung der unterbrechungsfreien Verfügbarkeit mit Hilfe von Clustering und/oder von Virtualisierung. Erst die Möglichkeit die Speichercluster fast beliebig auszuweiten, um z. B. hunderte von Knoten zusammenschalten zu können, verschafft Speicher-Grids die nötige Power, um das Kapazitätswachstum, aber auch die Performanceanforderungen der Applikationen unterbrechungsfrei zu bewältigen. Virtualisierung ist ebenfalls ein Knackpunkt im Speicher-Grid. Damit lässt sich die Komplexität für den Anwender verbergen. Hier sind virtuelle Datencontainer im Kommen, die auf einem Speichersystem die physikalischen Bereiche definieren, auf die eine Applikation exklusiv Zugriff hat. Dabei werden die Festplatten als Datencontainer virtualisiert. Ein Container kann einerseits beliebig viele Festplatten umfassen. Andererseits kann dieselbe Festplattengruppe mehrere Container enthalten. Die Daten im Container lassen sich als Verzeichnis darstellen, aber auch als Datei, Raw-Device oder Filesystem. Das Verschieben der Container von einem Speichersubsystem auf ein anderes ist problemlos möglich, so dass die Performance im Speicher-Grid jederzeit dem Bedarf entspricht. Sobald sich eine Speicherinfrastruktur über ein einzelnes Rechenzentrum ausdehnt und die Dimensionen einer weltweiten Datenstruktur zu berücksichtigen sind, werden einige Faktoren besonders wichtig. Essenziell ist z. B. ein „Unified System Image“, also die einheitliche Sicht auf die Daten für alle Nutzer – unabhängig davon, wo sie physikalisch gespeichert sind. Im Prinzip wird hier eine einzige, gigantische Festplatte präsentiert. Aus Sicht der Administration werden dabei Ressourcen und Nutzer verwaltet, aber nicht die Systeme, die aufgrund der Virtualisierung verborgen bleiben. Greift ein Nutzer auf Daten zu, die an einem entfernten Standort gespeichert sind, muss die Performance des Speicher-Grids dennoch dem eines lokalen Zugriffs entsprechen.

342

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Dem Speicher vorgeschaltete „Cache Appliances“ sind hier eine interessante zusätzliche Option, um den Zugriff auf die Daten zu beschleunigen. Ähnlich dem Web-Caching werden häufig angefragte Daten im Cache-Speicher vorgehalten und nicht jedes Mal von ihrem eigentlichen Speicherplatz abgerufen. Hier entsteht eine Situation, die kontrovers zum üblichen hierarchischen Speichermanagement ist. Statt die aktuell nicht mehr benutzten Daten auf nachgeordnete Speicherplatten zu verlagern, werden hier die Daten in einem Speicher-Grid gezielt online bzw. auf die Cache-Appliance geholt, die häufig gebraucht werden. Aufgrund der verteilten Datenspeicherung und ihrer Anbindung über WAN ist letztlich ein zentrales Management ebenso unabdingbar wie die Möglichkeit, Regeln zentralisiert aufzusetzen. Die damit einhergehende Automatisierung ist der Vorteil der Speicher-Grids schlechthin, da sie die Kosten einer Speicherinfrastruktur unmittelbar senkt. Die Speicher-Grid-Technik beeinflusst zudem das Verhältnis von Mensch und Technik. Bisher wurden die Arbeitsprozesse und damit der Mensch davon bestimmt, was IT-technisch machbar war. Mit Speicher-Grid kehrt sich dies um. Die Daten folgen dem Nutzer – wohin auch immer.

11.9 Antwort: Nutzung des Online-Datenschutzes für Backup und Disaster Recovery Zu den wichtigsten Erkenntnissen aus der WTC-Katastrophe gehört die große Bedeutung des Online-Datenschutzes. Der schnelle und sichere OnlineDatenschutz ist besonders immer dann wichtig, wenn unter allen erdenklichen Umständen der Geschäftsbetrieb für den definierten Zeitraum aufrechtzuerhalten ist, der für die Wiederherstellung nach einem Katastrophenfall benötigt wird. Dem Online-Datenschutz kommt dabei eine Schlüsselfunktion zu. Die Analyse einschlägiger Vorfälle zeigt zudem, wie wichtig die kontinuierliche Überwachung der Onlineoperationen ist, um einen unterbrechungsfreien Betrieb sicherzustellen. Dies ist annähernd ebenso wichtig wie die Band-Backups selbst. Automations-Tools, die eine konstante Überwachung sicherstellen und jederzeit kohärente und verwendbare Daten liefern, sind dabei entscheidend. Die Analyse der Abläufe in Katastrophenfällen und der entsprechenden Übungen zeigt folgende Verfahrensschwierigkeiten, die ein Disaster Recovery verzögern: x Das Fehlen einer Führungsstruktur bei Disaster Recovery (DR-) Vorgaben, x Verwirrung und Zeitverlust durch Mängel bei der Übergabe zwischen den einzelnen Arbeitsschichten, x Keine festgelegte Aufgabenliste, veränderte Aufgabenverteilung von Schicht zu Schicht, x Keine Überwachung und Kontrolle von Veränderungen, x Fehlende Dokumentation, x Eine zu enge Sichtweise auf die Aufgabenstellung,

11.9 Antwort: Nutzung des Online-Datenschutzes für Backup und Disaster Recovery

343

x Daten wurden nur auf Band gesichert, ohne Einsatz von Softwarelösungen für den Schutz von abhängigen Servern und Anwendungen, x Keine automatisierten Verfahren für das Auffinden der Bänder, x Probleme durch Veränderungen an bereits funktionierenden Systemen, x Mangel an qualifizierten Ressourcen bei den Unternehmen, x Mangelnde Führung (unpassende Anweisungen durch das Topmanagement erschwerten die Recovery-Bemühungen und übten zusätzlichen Druck auf das IT-Personal aus), x Kein dediziertes Dokument, das die Umgebung, Inhalte von Backups oder das Netzwerksetup beschreibt und x In vielen Fällen ist kein Online-Datenschutz vorhanden. Auf der Basis der obigen Erfahrungen lassen sich folgende wichtige Anforderungen an die Disaster Recovery (DR-) Planung ableiten: x x x x x x x x x

Keine Systeme mit „single Point-of-Failure“ einsetzen, Verteilte Netzwerke bevorzugen, Komplette und regelmäßige Tests aller Backup-Einrichtungen durchführen, Dokumentation der System-Konfigurationen erstellen, Dokumentation der DR-Prozeduren erstellen, Dokumentation genauso penibel wie Daten zu schützen (ILM-konform), Dokumentation und Tracking der Bänder implementieren, Geschäftskritische Systeme identifizieren und schützen, Alle Softwareoptionen zum Schutz von Servern, Anwendungen und Bandmedien zusätzlich zu den Daten sichern.

Vor dem Hintergrund dieser Erfahrung waren die beiden Autoren bei der Planung, den Tests und den ersten Umsetzungen einer über zwei Standorte verteilten Produktion (einer sogenannten Twin-Core-Produktion) beteiligt, die gemäß unseres Modells als „Disaster-Tier 8“ bezeichnet wird (für Details siehe Kap. 8, Schlüsselfaktor Security) . Die Kennzeichen einer Twin Core beziehungsweise einer Produktion gemäß dem Tier-8-Modell sind: x Verteilte Produktion über zwei Standorte, x In jeden Standort ist mindestens die Infrastruktur aufgebaut, die für die Erfüllung der Minimal-SLA erforderlich ist, falls ein Standort teilweise oder ganz ausfällt, x Backup vice versa in die jeweils zweite Site, x Betrieb der Server im Cluster oder als „virtueller Server“, x Automation des vollständigen Schwenks von Standort zu Standort, x Garantierte logische Datenbestände und x Kostenreduktion, da keine Infrastruktur nur für einen K-Fall vorgehalten wird, sondern immer auch produktiv genutzt wird.

344

11 ILM vor dem Hintergrund der sich abzeichnenden Trends

Das Ziel einer deutlich verbesserten Wertschöpfung auch für eine Produktion unter Einbeziehung eines zusätzlichen Disaster-Recovery-Standortes kann erreicht werden, wenn Ihr Motto lautet: Wenn man ohnehin einen komplett ausgestatteten zweiten Standort für den Notfall unterhalten muss, warum sollte man ihn die restliche Zeit ungenutzt lassen!

12 ILM Projektmanagement • Kurzbeschreibung Organisation und Struktur

Wie bereits festgestellt gilt insbesondere für ILM-Projekte: „Auch der längste Weg beginnt mit dem ersten Schritt.“207 Sie sollten nach dem Studium des Buches vor dem Hintergrund der beschriebenen Anforderungen und Risiken nicht zu der Erkenntnis gelangen, dass ILM für ihr Unternehmen zu anspruchsvoll oder zu komplex ist. Wichtig für uns ist, dass Sie die Erkenntnis aus der Lektüre mitnehmen, dass ILM-Projekte weder eine Laisser-faire-Vorbereitung noch eine Nonchalance-Durchführung erlauben. Allen Lesern, die nach der Lektüre dieses Buches die sicher notwendige Detailinformation für die Vorbereitung konkreter ILM-Projekte nutzen möchten, sei deshalb der Band „Information Lifecycle Management – Prozessimplementierung“ empfohlen. Aufsetzend auf unseren langjährigen Erfahrungen bei der erfolgreichen Durchführung einschlägiger, größerer Projekte in den Branchen Banken, Energieversorger, Handel und Telekommunikation in Zusammenarbeit mit den führenden Anbietern von SAN-, NAS- und Speicherlösungen einschließlich deren Management beschreiben wir im zweiten Band die Einführung eines geschäftsorientierten Informationsmanagements. Aus rechtlichen Gründen und um auch kritische Sachverhalte objektiv darstellen zu können, erfolgt die Beschreibung auf Basis eines fiktiven Unternehmens. Dieser Band erläutert das Vorgehen, die Planung, die Realisierung und die Projektkontrolle des Projektes KONCOM/IT durch die WeDo-IT-Projektmanagement anhand neutralisierter und anonymisierter Daten dreier tatsächlich durchgeführter Projekte. Hierzu beschreiben und begründen wir zunächst den Projekt- und Projektmanagementansatz zur Implementierung von Informationsmanagement und Information Lifecycle Management. Wir zeigen auf, dass die Komplexität der Aufgabe zwingend eine Herauslösung des Themas aus dem Tagesgeschäft und zusätzliche eine eigene spezifische Projektorganisation erfordert.

 207

Chinesische Weisheit, http://www.onlinecat.de.

346

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

12.1 Projektkurzbeschreibung Die „EurAmFi AG“208 ist ein international tätiger Energieversorger mit Hauptsitz in Deutschland und mehreren Tochtergesellschaften im europäischen Ausland sowie zwei Tochtergesellschaften in den Vereinigten Staaten von Amerika. Die EurAmFi AG beabsichtigt, im Rahmen einer anstehenden Speicherkonsolidierung ein Drei-Ebenen-Modell ihrer kompletten Produktions-IT-Speicherinfrastruktur zu implementieren, um den unterschiedlichen Anforderungen an die Datenverarbeitung und Datenhaltung von Informationen über den Verlauf ihres Lebenszyklus gerecht zu werden. Das Projekt „KONCOM/IT – Konsolidierung und Compliance der IT der EurAmFi AG“ soll die 92 existierenden Speichersysteme älterer Bauart auf High-Performance-Systeme mit zugehöriger SAN-, NASoder iSCSI-Infrastruktur konsolidieren. Dies erfolgt mit modularen Komponenten, die neu beschafft werden. Weiterhin soll sichergestellt werden, dass nach einer durchgeführten Datenklassifizierung der Produktivdaten sämtlicher Anwendungen der EurAmFi AG in den Datenklassen (Datenklasse 1 – Hochproduktivdaten, Datenklasse 2 – Nearline-Daten und Datenklasse 3 – Archivdaten) auf unterschiedlichen Speicherplattformen betrieben werden. Dabei sollen die Daten der Datenklasse 1 auf hochverfügbaren Speichermedien abgelegt werden. Diese sollen zur Sicherstellung der Katastrophenfallfähigkeit als Komponenten auf beide RZ-Standorte Hauptverwaltung (RZ 1) und Technikzentrum (RZ 2) verteilt werden. Daten der Datenklasse 2 sollen durch ein geeignetes Verfahren lokal abgesichert werden. Ein K-Fall-Szenario ist für diese Daten nicht vorgesehen. Daten der Datenklasse 3 sollen auf einem Archivierungssystem mit Hilfe der Archivierungssoftware IXOS abgelegt werden. Im Rahmen eines Vorläuferprojektes von KONCOM/IT wurden ebenfalls die existierenden Serversysteme unterschiedlicher Hersteller (IBM/AIX, SUN/Solaris, FSC/Solaris, FSC/W2K3, FSC/Linux) auf 384 moderne Systeme konsolidiert. Die Migration der Anwendungen und Services dieser Server auf die neuen Serverplattformen soll möglichst ohne Unterbrechung des Betriebes stattfinden. Dieser Refresh der EurAmFi-Umgebung mit sämtlichen Services sowie mit sämtlichen Produktiv-, PreLife-, Testinstanzen erfordert die Migration auf die High-Performance-Systeme sowie die Anpassung der datenverarbeitungstechnischen Prozesse in der neuen Umgebung, die von der EurAmFi Business Services GmbH betrieben wird. Bei den Services handelt es sich um die produktiven Kernapplikationen des Handels- und Abrechnungssystems der EurAmFi AG, geliefert von SAP, energieversorgerspezifische Anwendungen, basierend auf GIS-Systemen, sowie die komplette IT-Anwendungslandschaft der EurATel GmbH, inklusive einem zugekauften Rating- und Billing-System sowie einem CRM-System von Siebel. Die folgenden Informationen sind die Anforderungen, die die EurAmFi AG  208

Das hier beschriebene Projekt ist eine Zusammenführung dreier real durchgeführter ILMProjekte. Aus Gründen des Kundenschutzes wurden die in diesen Projekten verwendeten Daten anonymisiert. Die fiktive Gesellschaft EurAmFi AG wurde eingeführt, um die Relevanz eines international orientierten Vorgehens schon im Namen zu verdeutlichen.

12.2 Anforderungen an das Projektmanagement

347

an den externen Dienstleister „WeDo-IT – IT-Projektmanagement“209 gerichtet hat, der im Namen und Auftrag der EurAmFi AG das Pflichtenheft und die Projektausschreibung erstellen und die Implementierung von KONCOM/IT durch die ausgewählten Lieferanten planen und steuern wird.

12.2 Anforderungen an das Projektmanagement 12.2.1 Allgemeine Anforderungen an das Projektmanagement Speichermigrations- oder auch ILM-Projekte in Verbindung mit der Optimierung der Geschäftsprozesse sind in der Regel komplex. Die Leitung von Projekten ist deshalb eine Aufgabe geworden, für die der jeweilige Manager ein umfangreiches Portefeuille von Fertigkeiten benötigt. Nur durch ein wirkungsvolles Management können anspruchsvolle Projekte sicher termin-, kosten- und qualitätsgerecht zum Ziel geführt werden. Der Projekterfolg hängt dabei entscheidend vom Projektmanagement ab. Die Komplexität der Planung und der Steuerung der Durchführung des beschriebenen Projektes erfordert es, aus einem Portfolio von Projektmanagement-Ansätzen den für die jeweiligen Anforderungen geeigneten Lösungsbaustein zu nutzen und diese zu einem harmonischen Ganzen zu kombinieren.

12.2.2 Anforderungen an ein V-Modell- und V-Modell-XTbasiertes Projektmanagement Das V-Modell und die Weiterentwicklung V-Modell-XT ist eine umfassende Sammlung von Wissen über die „Best Practices" der Softwareentwicklung. Das Vorgehensmodell ist ein Prozessmodell, mit dessen Hilfe Projekte gemäß der Norm ISO 9001 abgewickelt werden können und das sowohl im militärischen Bereich als auch im gesamten Bereich der Bundesverwaltung (hier verbindlich) sowie von sehr vielen Industriefirmen eingesetzt wird – somit auch von der aus kommunalen Energieversorgern hervorgegangenen EurAmFi AG als Hausstandard zur Softwareentwicklung. Im V-Modell wird das Projektmanagement in Form eines Prozesses beschrieben. Dies geschieht durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen. Neben den vorgegebenen Aktivitäten und Produkten enthält das V-Modell auch Informationen über den Projektablauf. Im V-Modell wird geregelt, welche  209

Wie die EurAmFi AG und die EurATel GmbH ist auch die WeDo-IT-Projektmanagement ein fiktives Unternehmen. Tatsächlich haben die beiden Autoren die drei Projekte, die hier zum ebenfalls fiktiven KONCOM/IT zusammengefasst wurden, als Projektleiter im Namen und Auftrag unterschiedlicher Dienstleistungsunternehmen erbracht, die ebenfalls aus Kundenschutzgründen nicht genannt werden sollen.

348

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Ausgangsprodukte von einer Aktivität erzeugt werden und welche nachfolgenden Aktivitäten diese Produkte als Eingänge benötigen. Das Vorgehensmodell beschreibt so die Aktivitäten (Tätigkeiten) und Produkte (Ergebnisse), die während der Entwicklung von Software durchzuführen bzw. zu erstellen sind. Der Einsatz des V-Modells eröffnet die Chance zum maschinellen Workflow-Management. Aus dem inhaltlichen Produktfluss lässt sich eine zeitliche Abfolge der Aktivitäten ableiten. Diese Eigenschaft des V-Modells ist der Schlüssel zur maschinellen Steuerung von IT-Projekten im Sinne eines Workflows. Die Mitarbeiter der WeDo-IT erstellen die Grundlagen und überwachen die Ausführung gemäß dem V-Modell. Bei Bedarf erstellt die WeDo-IT die V-Modellkonforme Dokumentenstruktur und legt Struktur und Dokumente in einem Versionsmanagementsystem ab. Die WeDo-IT-Projektmanagement erstellt sowohl ein detailliertes Pflichtenheft als auch die Ausschreibungsunterlagen für das KONCOM/IT-Projekt und überprüft deren gesamte V-Modell-konforme Umsetzung. Die WeDo-IT-Projektmanagement bietet ein auf die Aufgabenstellung des KONCOM/IT optimiertes Projektmanagement als Dienstleistung an, basierend auf ihrem Fach-Know-how, das auch von unabhängigen Dritten bereits zertifiziert wurde.

12.2.3 Anforderungen an das Projektmanagement hinsichtlich ISO-20000-konformer Optimierung der ServiceGeschäftsprozesse ISO 20000 – der weltweite Standard im IT-Service – beschreibt den Wandel von der technisch orientierten IT-Abteilung zum kundenorientierten Dienstleister. ISO 20000 in Verbindung mit ITIL beinhaltet eine umfassende fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. An der Entwicklung von ITIL waren IT-Dienstleister, Mitarbeiter aus Rechenzentren, Lieferanten, Beratungsspezialisten und Ausbilder beteiligt. Unter anderem deshalb bieten ISO 20000 und ITIL die Grundlage zur Verbesserung von Einsatz und Wirkung einer an den Geschäftsprozessen angepassten IT-Infrastruktur. Die zusätzliche Erfahrung eines versierten externen Beraters kann dabei helfen, aus den festgefahrenen Strukturen auszubrechen. ISO 20000 und ITIL beschreiben ein systematisches, professionelles Vorgehen für das Management von IT-Dienstleistungen. Das entwickelte Servicekonzept stellt nachdrücklich die Bedeutung der wirtschaftlichen Erfüllung der Unternehmensanforderungen in den Mittelpunkt und erzielt die folgenden Vorteile: x Unterstützung der Geschäftsprozesse, x Definition von Funktionen, Rollen und Verantwortlichkeiten im Servicebereich, x Weniger Aufwand bei der Entwicklung von Prozessen, Prozeduren und Arbeitsanweisungen und x Höhere Kundenzufriedenheit durch bessere und messbare Verfügbarkeit und Performance.

12.2 Anforderungen an das Projektmanagement

349

ISO-20000- und ITIL-basierte Projekte stehen damit für höhere Produktivität und Effizienz. In 90 Prozent aller Fälle lassen sich binnen 24 Monaten Einsparungen zwischen 15 bis 30 Prozent erzielen, ohne dass die Unternehmen an Effizienz einbüßen, so die Analyseergebnisse der Computerwoche, die durch die EurAmFi-eigenen Projekt- und Betriebserfahrungen bestätigt werden. Die im Projekt KONCOM/IT zu erreichende Optimierung der Geschäftsprozesse zur Senkung der Total Cost of Ownership (TCO) bei der Speicherung von Informationen muss seitens der WeDo-IT durch Einhaltung der ITIL Best-Practices eingehalten werden. Die mangelnde Kosteneffizienz der einzelnen Dienstleistungen ist häufig das Kernproblem bei der Optimierung von Geschäftsprozessen. Durch den TCO-Ansatz wird eine sinnvolle Grundlage für die Leistungsverrechnung geschaffen. Im TCO-Ansatz werden zusätzlich zu den Kostenmodellen x Plankostenrechnung und x Prozesskostenrechnung auch der Nutzen der einzelnen IT-Services ermittelt und den Kosten gegenübergestellt. Ziel der TCO-basierten Kosten- und Leistungsverrechnung ist es, die tatsächlich entstandenen Kosten transparent aufzuzeigen und dem Kunden so nur die tatsächlich erbrachte Leistung in Rechnung zu stellen. So kann kontinuierlich die Effizienz des Einsatzes der IT-Infrastruktur sichergestellt werden. Die WeDo-IT kann aufgrund ihrer Erfahrungen bei verschiedenen IT-Kostenanalyse-Projekten aufzeigen, dass durch die erhöhte Transparenz bereits signifikante Kosteneinsparungen realisierbar sind. Der ITIL-basierte Prozess Financial Management ist als Regelkreis konzipiert mit der Anforderung der effizienten Erstellung des IT-Service als Eingangsgröße, der Regelstrecke IT-Services und den Stellgrößen x IT-Operationsplan, x Kostenanalyse und x Kostenverrechnung. Ziel ist es, eine kosteneffektive Bereitstellung des vereinbarten IT-Servicelevels zu erreichen. Die Ergebnisse des ITIL-basierten Prozesskostenmanagements beeinflussen wiederum direkt die ITIL-basierten Prozesse x Service Level Management, x Capacity Management und x Configuration Management.

350

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

12.3 Aktivitäten der Startphase 12.3.1 Zielsetzung Das Ziel des Projektleitfadens ist es, die wesentlichen organisatorischen Rahmenbedingungen für die Laufzeit des Projektes zu etablieren und die Zuständigkeiten der beteiligten Akteure festzulegen. Dies beinhaltet: x x x x

eine Übersicht über die Projektorganisation, die Darstellung der Aufgaben, Zuständigkeiten und Kompetenzen, die Einführung von Methoden, Berichtswesen und Kommunikation, die Darstellung der Eskalationspfade im Falle dringender Projektentscheidungen und x eine Übersicht über die Projektmitglieder und ihre Funktionen.

12.3.2 Geltungsbereich Die Geltung dieses Projektleitfadens beginnt mit der Unterzeichnung des Angebotes durch die EurAmFi AG und endet mit dem Abschluss des Projektes.

12.3.3 Projektgremien Im Folgenden werden die für die Projektorganisation relevanten Gremien kurz aufgeführt und ihre Rollen und Verantwortlichkeiten beschrieben.

12.3.3.1 Entscheidungsgremium Das Entscheidungsgremium dient als letzte Entscheidungs- und Schlichtungsinstanz im Falle von Eskalationen oder wesentlichen Projektentscheidungen, die von den ausführenden Projektmitgliedern nicht getroffen werden können (etwa weil sie nicht mit den entsprechenden Weisungsbefugnissen ausgestattet sind oder weil zusätzliche Gelder bewilligt werden müssen). Das Entscheidungsgremium ist nicht aktiv in den operativen Projektverlauf eingebunden, wird jedoch bei Bedarf durch den Lenkungsausschuss hinzugezogen.

12.3.3.2 Lenkungsausschuss Der Lenkungsausschuss ist das zentrale Steuerungsgremium des Projektes. Er überwacht den Projektfortschritt und die Einhaltung der vereinbarten Meilensteine. Er dient als Anlaufstelle bei Problemen, die nicht auf operativer Ebene gelöst werden können, oder bei wesentlichen Abweichungen von den vereinbarten Projektgrößen (Qualität, Termine, Kosten). Der Lenkungsausschuss wird regelmäßig über den Projektverlauf unterrichtet (siehe Berichtswesen) oder kann auf seine Initiative hin Berichte über den aktuellen Projektstand durch die Projektmanager einfordern.

12.3 Aktivitäten der Startphase

351

12.3.3.3 Projektmanagement-Team Das mit der Durchführung des Projektes betraute Projektmanagement-Team ist für die Planung, Koordination und Steuerung der Projektaktivitäten verantwortlich. In dieser Funktion stimmen sie die unterschiedlichen Aufwände der beteiligten Organisationen (EurAmFi AG, WeDo-IT) ab und planen die Einsätze der für die jeweilige Projektphase notwendigen Mitarbeiter. Der Projektverlauf und die Einhaltung der vereinbarten Meilensteine werden überwacht; bei Planabweichungen werden Gegenmaßnahmen innerhalb des Gremiums vereinbart und an den Lenkungsausschuss kommuniziert. Das Projektmanagement erstellt in regelmäßigen Abständen Statusberichte über den aktuellen Projektverlauf.

12.3.4 Gesamtprojektplan Für den Verlauf des Projektes wird ein Gesamtprojektplan erstellt, in dem die einzelnen Phasen zusammen mit ihren Meilensteinen und Verantwortlichkeiten beschrieben werden. Dieser Projektplan wird mit MS Project 2003 erstellt. Der erste Entwurf des Projektplanes erfolgt durch die Projektleiter der Firmen EurAmFi AG und WeDo-IT-Projektmanagement. Der so erarbeitete Projektplan gilt als produktiv, sobald er im Projekt-Kick-off-Meeting abgenommen wird. Er ist damit für den weiteren Projektverlauf die verbindliche Planungsgrundlage. Änderungen beziehen sich fortan immer auf den Gesamtprojektplan und werden zentral von beiden Projektleitern, federführend vom Projektleiter der WeDo-IT-Projektmanagement verwaltet.

12.3.4.1 Verwaltung des Masterplans Da in KONCOM/IT mehrere Organisationen eingebunden sind (EurAmFi AG, WeDo-IT-Projektmanagement) und keine einheitliche Projektmanagementplattform existiert, ist es notwendig, den Gesamtprojektplan zentral zu verwalten, um Mehraufwände und Inkonsistenten zu vermeiden. Um die damit verbundenen administrativen Aufwände möglichst gering zu halten, übernimmt der Projektmanager der WeDo-IT-Projektmanagement die Ownership des Masterplanes. Änderungen des Masterplanes werden an die EurAmFi-Projektleitung kommuniziert und von ihr zur internen Verwendung gepflegt. Die neue Version des Projektplanes wird dann den Projektbeteiligten im Adobe PDF-Format zur Verfügung gestellt.

12.3.4.2 Teilabnahme von Projektmeilensteinen Der Projektplan ist in einzelne Phasen untergliedert, die durch einen klar definierten Meilenstein abgeschlossen werden. Nach Abschluss eines Meilensteines wird das Ergebnis durch die Projektleiter abgenommen und protokolliert. Die gegebenenfalls für die Abnahme notwendigen Dokumente und Ergebnisse werden dem Projektleitergremium rechtzeitig (2 Tage vorher) zur Verfügung gestellt.

352

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

12.3.5 Berichtswesen Mit dem eigentlichen Beginn des Projektes (Annahme des Angebotes, Kick-offMeeting) werden regelmäßige Statusberichte erstellt, die den aktuellen Projektverlauf zusammenfassen und bewerten. In diesen Statusberichten wird über folgende Punkte informiert: x x x x x x x

Beschreibung der laufenden Aktivitäten, aktueller Projektstand, aktueller Fertigstellungswert, gegebenenfalls Abweichungen und Probleme, Risiken und Maßnahmen zu ihrer Behebung, Termine und Verantwortlichkeiten.

Um den daraus resultierenden administrativen Aufwand möglichst gering zu halten, ist es sinnvoll, die Erstellung der Statusberichte mit der Pflege des Masterprojektplanes zu koppeln. Damit gehört diese Aufgaben in den Verantwortungsbereich des Projektmanagers der WeDo-IT-Projektmanagement, der darin vom Projektkontroller unterstützt wird.

12.3.6 Änderungsmanagement Die in dem unterzeichneten Angebot vereinbarten Leistungen und Services bilden den Rahmen für alle Projektaktivitäten. Diese werden in einem gemeinsam von beiden Projektleitern erstellten Statement of Work (SOW) dokumentiert. Sollten sich während des Projektes notwendige Änderungen an dem Leistungsportfolio ergeben, dann werden sie schriftlich als Change Request dokumentiert und zur Entscheidung an die jeweiligen Projektgremien übergeben.

12.3.6.1 Projektänderungsantrag Jede Änderung dieser Projektbeschreibung (SOW), unabhängig von der Auswirkung, wird über einen Projektänderungsantrag, der von der EurAmFi AG beauftragt werden muss, mit folgendem Inhalt abgewickelt: x gewünschte Änderung mit genauer Beschreibung, x Notwendigkeit der Änderung (Auswirkung bei Nichtdurchführung) und x Auswirkungen (auf bereits verabschiedete Arbeitsergebnisse). Der Antragsteller muss seinen Änderungswunsch so genau spezifizieren, dass EurAmFi AG/WeDo-IT in die Lage versetzt werden, den Antrag auf der Grundlage der verabschiedeten Projektergebnisse prüfen zu können.

12.3 Aktivitäten der Startphase

353

12.3.6.2 Projektänderungsprüfung EurAmFi AG und WeDo-IT-Projektmanagement werden die gewünschte Änderung auf der Basis vorhandener und verabschiedeter Projektdokumente sorgfältig analysieren und dem Projektmanagement-Team von KONCOM/IT als Entscheidungsgrundlage folgende Informationen zur Verfügung stellen: x Analyseergebnisse (Abhängigkeiten), x Realisierungsvorschlag mit einer Kurzbeschreibung der möglichen Durchführung und x Auswirkungen auf Kosten und Termine.

12.3.6.3 Projektänderungsauftrag Mit der Unterschrift beider Vertragspartner auf dem Projektänderungsantrag und/oder einem begleitendem Nachtragsangebot, gilt die Änderung als beauftragt.

12.3.6.4 Umsetzung der Projektänderung Im Falle der Durchführung der Änderung wird das Änderungsformular Basis für die Änderung oder Ergänzung des aktuellen Projektplanes.

12.3.7 Definition der Projektziele 12.3.7.1 Der Projektauftrag Zum Zeitpunkt des Projektstarts werden bei der EurAmFi AG in den drei Standorten/Rechenzentren x Hauptverwaltung (RZ 1), x Technikzentrum (RZ 2) und x Notfallrechenzentrum (RZ 3) 92 Speichersysteme älterer Bauart betrieben. Die Zielsetzung für KONCOM/IT ist gemäß Projektauftrag aus TCO-Aspekten bzgl. der voraussehbaren Wartungskosten und zur Ausnutzung der technologischen Weiterentwicklung diese Systeme auf „Tiered“-Speicherneusysteme zu konsolidieren, die den unterschiedlichen Wertigkeiten der gespeicherten Daten in ihrem Lebenszyklus gerecht werden. Dabei sollen die Daten in drei Datenklassen (Hochproduktivdaten, Nearline-Daten, Archivdaten) untergliedert und dementsprechend auf die Neuinfrastruktur migriert werden.

354

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Dieser Projektauftrag wurde in Detaillierungsgesprächen durch folgende Zielsetzungen erweitert. Unter betriebswirtschaftlichen Gesichtspunkten soll mit dem Projekt KONCOM/IT x x x x x x x

die Kostenreduzierung für den laufenden Betrieb, die Vereinfachung der betrieblichen Prozesse, die Normierung der Geschäftprozesse an den Standorten/Rechenzentren, Einbettung der Standorte/Rechenzentren in eine unternehmensweite Strategie, Ausschöpfung des Potenzials für die Automatisierung von Prozessen, lebenszykluskonforme Datenspeicherung und Einhaltung der Compliance der Datenhaltung zur relevanten Gesetzes- und Verordnungslage im internationalen Markt der EurAmFi AG

mit Berücksichtigung der Einmalkosten für eine schnelle Aufnahme des Betriebs der Zielumgebung erreicht werden. Für die Überführung in die konsolidierte „Tiered“-Zielspeicherumgebung sind folgende Anforderungen für die Kategorien von Speichersystemen gegeben: x Überführung der Host Connectivity von SCSI in eine switched SAN-Umgebung und x Migration und Anbindung von 384 Servern und Clustern einschließlich den auf diesen betriebenen Applikationsinstanzen. Dieses Zielbündel erfüllt nicht die Anforderung der Quantifizierbarkeit/Operationalität.210 Die Operationalisierung der Ziele folgt im Vorgang zur ProjektKick-off-Veranstaltung.

12.3.7.2 Wesentliche Randbedingungen für die Realisierung des Projektes Als projektbestimmende Anforderung ist definiert, dass die Migration und Konsolidierung mit minimalen geplanten Applikationsauszeiten sowie ohne jede ungeplante Applikationsauszeit und insbesondere ohne Datenverlust erreicht werden muss.

12.3.7.3 Projektziele Der Zielfindungsprozess ist Bestandteil der dreitägigen Projekt-Kick-off-Veranstaltung. Der Projektmanager der EurAmFi AG, der Projektmanager seitens WeDo-IT-Projektmanagement und der Projektsponsor der EurAmFi AG operationalisieren vor Beginn der Kick-off-Veranstaltung die im Projektauftrag vorgegebenen Ziele aus dem Vertragswerk zu einem Projektziel, das als Einziges vor Beginn der Kick-off-Veranstaltung vorgegeben wird. Als Projektziel für KONCOM/IT wurde definiert:  210

Grau, Nino: Projektziele, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.155.

12.3 Aktivitäten der Startphase

355

„Erstellung des Pflichtenheftes und der Ausschreibungsunterlagen, Durchführung der Ausschreibung, Lieferantenauswahl sowie Planung und Durchführung der Konsolidierung und Migration von 640 Anwendungen und 384 Servern und Clustern sowie 92 Speichersystemen älterer Bauart auf neue Speichersysteme in einer „Disaster Recovery“ (DR-) Umgebung in 2 Standorten. Einsparung von 11,2 Mio. Euro Wartungskosten über 4 Jahre. Einführung von SAN-Anschlusstechnik und zentralisierte Speicherverwaltung sowie Gewährleistung der Compliance durch lebenszykluskonforme Speicherung auf hochverfügbaren Speichersystemen mit Katastrophenfallschutz für Daten der Datenklasse 1 (Hochproduktivdaten), auf hochverfügbaren Speichersystemen ohne Katastrophenfallschutz für Daten der Datenklasse 2 (Nearline-Daten) und hochverfügbaren Archivsystemen für Daten der Datenklasse 3 (Archivdaten).“ Das Projektziel bestehend aus den drei Zielgrößen Kosten-, Qualität und Zeiten wurden in die drei Zielkategorien Kostenziele, Leistungsziele und Terminziele einschließlich der gesetzten Unterziele wie folgt untergliedert: Kostenziele Die Kostenziele waren: x Einsparung von 11,2 Mio Euro Wartungskosten über eine Laufzeit von 4 Jahren und x Die Projektmanagementkosten seitens WeDo-IT-Projektmanagement dürfen 1,2 Mio. Euro nicht übersteigen211. Die Unterziele bei den Kostenzielen waren: x Termingerechte Rückführung der Altsysteme zu jedem Monatsende, x Einsatz kostengünstigen Onsite-Personals und x Keine Freigabe neuer Kapazitäten auf den abzulösenden Altsystemen. Leistungsziele x Konsolidierung von 384 Server-Clustern und 640 Anwendungen von 92 Altspeichersystemen auf neue Speichertechnologie, x Aufbau einer K-Fall-Umgebung für die Server- und Cluster-Anwendungen der Datenklasse 1, x Aufbau der Umgebung ohne K-Fall-Schutz für die Server-und Cluster-Anwendungen der Datenklasse 2, x Aufbau einer Archivierungsumgebung für die Server- und Cluster-Anwendungen der Datenklasse 3, x Einführung der SAN-Anschlusstechnik, x Zentralisierung der Speicherverwaltung, x Gewährleistung der Compliance über den Informationslebenszyklus, x Erstellung des Pflichtenheftes und der Ausschreibungsunterlagen und x Durchführung der Ausschreibung und Lieferantenauswahl.  211

Internes Unterziel der WeDo-IT-Projeketmanagement.

356

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Die Unterziele bei den Leistungszielen waren: x Erstellung allgemeingültiger Migrationsstrategien und Konzepte, x Aufbau eines Qualitätssicherungssystems für den Übergang der Betriebsverantwortung auf Mitarbeiter der EurAmFi AG, x Erstellung allgemeingültiger Konfigurationsrichtlinien und automatisierter Prozesse für die Migrationen der Daten im Lebenszyklus, x Sicherstellung der aktuellen Performancewerte auf der Neuumgebung, x Sicherstellung der Dokumentation der Kapazitätszuweisungen und x Sicherstellung des unterbrechungsfreien Anwendungsbetriebs auf der Neuumgebung. Terminziele Projektende zur Realisierung der Kosteneinsparungen ist der 30.09.2004 Die Unterziele bei den Terminzielen waren: x Berücksichtigung der Frozen-Time der EurATel im Weihnachtsgeschäft und x Berücksichtigung der Frozen-Time der EurATel im Ostergeschäft. Das Projektziel wurde vor Projektstart vorgegeben. Die Unterziele wurden in dem dreitägigen Projekt-Kick-off-Meeting in zwei unterschiedlichen Gruppen festgelegt. Die eine der beiden Gruppen definierte die Ziele über das intuitive Verfahren Methode 635212. Die zweite Gruppe definierte die Ziele diskursiv über ein Analogieverfahren, bei dem ausgehend von komplexen Projekten aus der Vergangenheit die Ziele für das Projekt KONCOM/IT analog abgeleitet wurden. In der Gesamtrunde wurde dann der Konsens über die wesentlichen Unterziele erreicht.

12.4 Aktivitäten über die komplette Projektlaufzeit 12.4.1 Die Risikoanalyse Die Projektrisiken wurden im Kick-off-Workshop vom Team in Gruppen von jeweils 6 Teammitgliedern erarbeitet und im Plenum kondensiert und strukturiert. Die Abbildungen 12.1 bis 12.3 zeigen die erkannten Risiken auf. Neben den Risiken, die aufgrund der Interessenlage des Projektumfeldes für das Projekt existierten (Betroffene, Beteiligte), waren technische und organisatorische Risiken zu betrachten. Von den Betroffenen OS-CARBON und EurATel gehen, wie bereits in der Umfeldanalyse beschrieben, klare Risiken für das Projekt  212

Die Methode 635 ist als Kreativitätstechnik eine Weiterentwicklung der Brainstorming-Technik, bei der die Ergebnisse nicht mündlich geäußert und vom Moderator auf einem Medium notiert werden. Bei der Methode 635 schreiben 6 Gruppenmitglieder jeweils 3 Ideen auf ein Blatt Papier. Diese Papiere werden in einer vorgegebenen Reihenfolge genau 5-mal weitergegeben, wobei die Mitglieder jeweils wieder 3 Ideen notieren oder bereits auf dem Notizblatt stehende verfeinern. Vgl. dazu Bergfeld, Heinz: Kreativitätstechniken, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.813 ff.

12.4 Aktivitäten über die komplette Projektlaufzeit

357

Abb. 12.1. Risiken durch Beteiligte des Projektes KONCOM/IT

KONCOM/IT aus. Die OS-CARBON ist der klassische Betroffene des Projektes. Sie hat primär durch das Projekt keinerlei Nutzen. Ihre von der EurAmFi Business Services GmbH betriebene Anwendungsumgebung läuft stabil, die SLAs wurden bisher stets eingehalten. Die durch die Migrationsaktivitäten von KONCOM/IT für die OS-CARBON bestehenden Ausfallrisiken werden nicht durch Interessen der OS-CARBON am Projekt gedeckt. Die Risiken, die den Beteiligten des Projektes zugeschrieben werden können, sind klassische Kommunikations-, Ressourcen- und Interessenskonfliktrisiken. So sind im KONCOM/IT Projekt allein 11 Lieferanten zu koordinieren, die im

358

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Abb. 12.2. Technische Risiken des Projektes KONCOM/IT

Abb. 12.3. Organisatorische Risiken des Projektes KONCOM/IT

12.4 Aktivitäten über die komplette Projektlaufzeit

359

EurAmFi-Konzern im Wettbewerb zueinander stehen. So sind die Lieferanten EMC2, Hitachi Data Systems (HDS), SUN, StorageTek, IBM und Hewlett Packard (HP) Unternehmen, die für die Speichersystemkonsolidierung und die ILM-Archivierungs- und „Tiered“-Speicherlösung eine komplette Produktpalette anbieten können. LSI-Logic hat hier noch eine besondere Stellung inne, da sie sowohl als Direktanbieter für die Zielumgebung auftreten kann als auch als Komponentenlieferant für die übrigen Hersteller in Frage kommt. Die Softwarelieferanten SAP, Microsoft und Oracle stehen mit ihren Produkten im EurAmFi-Konzern zwar nicht in direkter Konkurrenz zueinander, müssen jedoch teilweise für Systemmigrationen zeitgleich ins Boot geholt werden, was Ressourcen- und Kommunikationsrisiken birgt. Die Risiken der beteiligten Teams der EurAmFi Business Services GmbH sind klare Ressourcenrisiken. Aufgrund der Größenordnung des Projektes müssen aus jedem Team des Bereiches Produktion der EurAmFi Business Services je zwei Mitarbeiter zur Projektunterstützung abgestellt werden. Dies betrifft die Teams Produktionssteuerung mit insgesamt 10 Mitarbeitern, Backup/Archivierung mit 5 Mitarbeitern, Datenbanken mit 8 Mitarbeitern, Application Support mit 8 Mitarbeitern, Storage mit 6 Mitarbeitern und Kapazitätsmanagement mit 3 Mitarbeitern. Das Delivery Management muss mit seinen Delivery Managern für die EurAmFi AG, die EurATel GmbH und die OS-CARBON im Projekt vertreten sein. Das Controlling der EurAmFi AG, die Rechtsabteilung der EurAmFi AG sowie die EurATel GmbH bergen Koordinationsrisiken, da diese jeweils rechtzeitig in das Projekt eingebunden werden müssen, jedoch klar formulierter Arbeitspakete mit wenig flexiblen Fertigstellungsterminen bedürfen. Insgesamt wird das Projekt KONCOM/IT in einer klassischen Matrixorganisation neben dem Tagesgeschäft betrieben. Dies bedeutet, Projektressourcen werden aus dem Tagesgeschäft freigestellt, solange dieses und damit die Linienorganisation nicht die Mitarbeiter benötigt. Dies stellt zumindest bei den Mitarbeitern der EurAmFi Business Services GmbH ein hohes Risiko dar, da diese bei Produktionsstillständen stets aus dem Projekt genommen werden können und Neugeschäft gegenüber dem Projekt priorisiert werden kann. KONCOM/IT birgt eine Vielzahl technischer Risiken. Die 640 Anwendungen liefen bisher auf insgesamt 92 Speichersystemen. Vom geplanten/ungeplanten Ausfall eines Speichersystems konnten somit durchschnittlich 7 Anwendungen betroffen sein. Die Konsolidierung wird auf deutlich weniger Speichersysteme neuerer Bauart stattfinden. Erste Planungen gehen von 16 Speichersystemen für alle 3 Datenklassen aus. Dies bedeutet, dass zukünftig durchschnittlich 40 Anwendungen von einem Ausfall nur eines Speichersystems betroffen sein können. Mit der steigenden Zahl von Anwendungen steigt auch der Koordinationsaufwand, gemeinsame Wartungszeiten für die betroffenen Anwendungen zu finden. Ein weiteres Risiko stellt – bei der kurzen terminlichen Gestaltung von KONCOM/IT – die Dauer der Hardwarebeschaffung dar. Hier muss über die Schritte Erstellung des Pflichtenheftes, Erstellung der Ausschreibungsunterlagen inklusive Entscheidungsmatrix, Durchführung der Ausschreibung, Bewertung

360

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

der Angebote, Vertragsverhandlung bis hin zur Lieferantenbeauftragung in kurzer Frist der technische Rahmen für KONCOM/IT gesetzt und fixiert werden. Ferner muss für KONCOM/IT zumindest für die Zeit der endgültigen Ablösung der Altsysteme die Infrastruktur vorhanden sein, die Neusysteme parallel zu den Altsystemen zu betreiben. In den vorgesehenen Rechenzentren muss Strom- und Notstromversorgung, Kühlleistung, Abwärmeleistung etc. für diese Neusysteme bereitgestellt werden können. Um eine zielgerichtete performanceoptimierte Migration auf die Neusysteme vorbereiten und die dafür erforderlichen Konfigurationsvorgaben erarbeiten zu können, werden verlässliche Performancedaten der Altumgebung benötigt. Diese wurden noch niemals in Gänze erfasst. Aufgrund der Inhomogenität der Altumgebung mit Speichersystemen unterschiedlicher Hersteller erscheint auch die Vergleichbarkeit als potenzielles Risiko. Für die Durchführung der Migration wird vor allem die Gefährdung der Verfügbarkeit der Applikationen während der Migration als Risiko gesehen. Um eine möglichst geringe Wahrscheinlichkeit der Nichtverfügbarkeit der Applikationen zu realisieren, kann über Springersysteme migriert werden. Dieses Migrationsverfahren ist jedoch sehr aufwendig, mit hohem Personaleinsatz verbunden, fehleranfällig und sehr QS-intensiv. Letztendlich wird die Komplexität der Compliance-Anforderungen als technisches Risiko von KONCOM/IT erkannt. Hier geht es um die vollständige Erfassung sämtlicher Vorschriften des nationalen, EU- und US-amerikanischen Rechtes. Die gemäß den Compliance-Anforderungen vorzunehmende Datenklassifizierung wird ebenfalls als Risiko betrachtet, da die Daten evtl. nicht immer datenklassengerecht gespeichert werden können. Dies muss jedoch der Projektverlauf ergeben. Die letzte Risikokategorie stellen die organisatorischen Risiken für das Projekt KONCOM/IT dar. Zu dem frühen Zeitpunkt der ersten Risikoanalyse (Projekt-Kick-off-Meeting) waren allein aus dem Projektmanagement diverse, schwerwiegende Risiken zu benennen. So führte z. B. die für den Umfang des Projektes kurze Projektlaufzeit dazu, dass von den Betroffenen und den Beteiligten weitere Risiken zusätzlich zu den bereits dargestellten technischen Risiken des Projektes genannt wurden. Der zum Zeitpunkt des Kick-off-Meetings unbekannte Ressourcenbedarf, der fehlende Meilensteinplan, die mangelnde Transparenz der Konsolidierung und der Abstimmungsbedarf zwischen sämtlichen beteiligten Einheiten, vor allem der chronisch überlasteten IT-Produktionseinheiten der EurAmFi Business Services stellten Risiken dar. Die geringe Erfahrung der EurAmFi bezüglich Konsolidierungsmaßnahmen dieser Größenordnung ist ein Risikofaktor für die Migration (einzelner) Applikationen. Organisatorisches Risiko wurde ebenfalls im Problem der Ausfallzeitenoptimierung der betroffenen Anwendungen inklusive der Einbindung der Kunden EurATel und OS-CARBON gesehen. Das Commitment sämtlicher Mitarbeiter aller beteiligter Organisationen musste kritisch hinterfragt werden, zumal KONCOM/IT – wie bereits erwähnt – auch mit den übrigen Projekten und dem Tagesgeschäft der beteiligten Unternehmen und Unternehmenseinheiten in Konkurrenz trat.

12.4 Aktivitäten über die komplette Projektlaufzeit

361

Abb. 12.4. Risikobewertung KONCOM/IT − Organisatorische Risiken

Diese Risiken wurden vom Projektmanagement bewertet, anschließend wurden Gegenmaßnahmen definiert und entsprechend der geschätzten Kosten entschieden, mit welchen Gegenmaßnahmen beim Eintreten der Risiken reagiert wird. Das Ergebnis der Analyse wurde mit dem Projektteam abgestimmt. Im Projektfortschritt wurden diese Risiken und die Wirksamkeit der Gegenmaßnahmen permanent überwacht. Diese Risikocheckliste wurde für weitere Projekte der EurAmFi AG fortgeschrieben.213 Die im Rahmen von KONCOM/IT erkannten Risikopotenziale von Migrationsprojekten sind in die Betrachtung sämtlicher weiterer Migrationsprojekte in den Häusern EurAmFi AG, EurAmFi Business Services GmbH und EurATel GmbH eingeflossen. Hier konnten vor allem bei der Behandlung des Risikos „Ressourcenprobleme aller Organisationseinheiten“ in der Multiprojektorganisation im Bereich der projektübergreifenden Einsatzmittelplanung zwischen sämtlichen beteiligten Unternehmungen und Organisationseinheiten durch ein umfassendes Ressourcen- und Kapazitätsmanagement Synergien erzielt werden, die sämtlichen Projekten nutzten.  213

Rohrschneider, Uwe: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.1091.

362

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Abb. 12.5. Risikobewertung KONCOM/IT − Technische Risiken

12.4.2 Projektstrukturierung Der im Folgenden definierte Projektstrukturplan (PSP) beschreibt die Projektstruktur von KONCOM/IT. Es handelt sich bei dem Projektstrukturplan von KONCOM/IT um einen gemischtorientierten PSP. Nach Schelle um eine Kombination von Objekt- und Funktionsgliederung.214 Sämtliche Teilaufgaben enthalten die Arbeitspakete x x x x

Planung, Konzeption/Design, Implementierung/Test und Abschlussarbeiten.

 214

Schelle, Heinz: Projekte zum Erfolg führen, 4. Auflage, München, 2004, S. 123.

12.4 Aktivitäten über die komplette Projektlaufzeit

363

Abb. 12.6. Projektstrukturplan KONCOM/IT

12.4.3 Berichtswesen, Statusgespräche und Projektinformationswesen Mit dem eigentlichen Beginn des Projektes (Annahme des Angebotes, Kick-offMeeting) wurde ein gemeinsamer Projektleitfaden entwickelt und abgestimmt, in dem die Erstellung regelmäßiger (wöchentlicher) Statusberichte beschlossen wurde, die den aktuellen Projektverlauf zusammenfassen und bewerten sollten. In diesen Statusberichten wurde das Management der EurAmFi AG, EurATel GmbH, EurAmFi Business Services GmbH und der WeDo-IT sowie der Lenkungsausschuss über folgende Punkte informiert: x x x x x x

Beschreibung der laufenden Aktivitäten, aktueller Projektstand, Fertigstellungswert, gegebenenfalls Abweichungen und Probleme, Risiken und Maßnahmen zu ihrer Behebung, Termine und Verantwortlichkeiten.

Die Abstimmung dieses wöchentlichen Statusberichtes war ebenfalls Gegenstand des gemeinsamen Projektmanagement-Meetings. Wöchentlich fand mit dem kompletten Team ein Projektmeeting statt. Dieses war mit einer StandardAgenda versehen und diente der Information des gesamten Projektteams. Das Protokoll des Projektmeetings wurde dem Team zur Verfügung gestellt. Die

364

12 ILM Projektmanagement − Kurzbeschreibung Organisation und Struktur

Statusinformationen der einzelnen Teilprojekte waren geprägt vom projektübergreifenden Austausch von Informationen. Hier konnte wiederum aufgrund des Informationsflusses sichergestellt werden, dass projektübergreifend die Aktivitäten der eingesetzten Ressourcen synchronisiert wurden. Unter anderem sorgte dies für eine nivellierte Qualität der Ressourcenauslastung über sämtliche Parallelprojekte bei der EurAmFi AG, der EurATel GmbH und der EurAmFi Business Services GmbH.

12.4.4 Projektsteuerung: Termin-, Leistungsund Kostensteuerung Die Projektplanung und -steuerung erfolgte in Microsoft Project 2003. Hierbei wurde der Basisprojektplan seitens des Projektmanagements gepflegt und die notwendigen Änderungen angepasst. Der Projektplan besteht aus über 400 Tasks sowie über 40 Teilprojektplänen für die serverbezogenen Migrationsaktivitäten mit jeweils über 40 Tasks. Zur Projektsteuerung wurden wöchentliche Statusmeetings mit sämtlichen Teilprojekten sowie das Berichtswesen herangezogen. In jeweils am Montagvormittag stattfindenden Projektmanagement-Meetings wurde der Projektfortschritt abgeglichen und die Projektplanung aktualisiert. Hierzu wurde der Plan-Fortschrittsgrad dem Fertigstellungsgrad als Verhältnis der zu einem gegebenen Zeitpunkt erbrachten Leistung zur Gesamtleistung der Vorgänge/Arbeitspakete/Projektphasen gegenübergestellt. Um die Zeiten in Relation zum bereits erfassten Aufwand bewerten zu können, wurde zusätzlich wöchentlich der Fertigstellungswert ermittelt und im Projektstatusbericht dem

Abb. 12.7. Aktionspunkteliste KONCOM/IT (exemplarisch)

12.4 Aktivitäten über die komplette Projektlaufzeit

365

Lenkungsausschuss mitgeteilt. Zur Vorbereitung des Statusberichts fanden innerhalb des Teams zweimal wöchentlich Feedbackrunden zum gegenwärtigen Stand der Vorgänge/Arbeitspakete statt. Anhand der Ergebnisse dieser Feedbackrunden konnte steuernd eingegriffen werden, indem – falls erforderlich – zusätzliche Ressourcen für die Bearbeitung der Arbeitspakete angefordert wurden. Änderungen wurden gemäß dem im Projektleitfaden und Statement of Work definierten Change-Prozess angefordert und durchgeführt. Zusätzlich zu der Steuerung der Vorgänge über diese Feedbackrunden wurde eine Aktionspunkteliste geführt, die bei Auftreten von Verzögerungen oder sonstigen Projektproblemen die Aktivitäten für die Teammitglieder anstelle des Projektplanes visualisierte.

Index

1 10-jährige Aufbewahrungspflicht 23 14 Punkte von Aufmerksamkeit für Manager 281 15-Zoll Format 15

2 24u7-Zugang 244 24/7 Zugreifbarkeit 18

7 7-Bit-EPS 272

8 802.1x 203 8-Bit-EPS 272

A Aberdeen Group 316 Abgabenordnung 60, 64, 65, 261 abgesandten Handelsbriefe 64 abgeschotteter Administrationsnetze 338 Ablauf der Aufbewahrungsfrist 193 Ableitung der Testfallspezifikation aus der UML-Darstellung 308 Abnahmeprüfung 293 Abschalten von Sicherheitsmechanismen 226 Abstimmung der Geschäftsprozesse mit den IT-Systemen und -Diensten 323 Abwendungs-Klassifizierung 178 Access Control Entries 201 Access Control List 198, 200, 203, 337 Accessibility Act 275 Accounting 196 ACE 201

ACL 198, 200, 203, 337 ACL-Systemen 200 Administration 338 Administration der Softwareinfrastruktur 45 Administrationsapplikationen 53 administrativen Bereich 2 Administrator 17, 196, 326 Adobe 269 Adobe Reader 274 Adobe Systems 272, 273 Adressinformationen im Datenfeld 214 Advanced-Encryption-Standard 242 AEAO 66 AES 196, 242 AES-Algorithmus 242 AES-Verfahren 242 Agenten 215 aggressive Preispolitik 9 AICPA 195, 332 AIIM 151 AIIM International 276 AIX 121, 257 aktive Verwaltung der Unternehmensdaten 2 akzeptablen Ausfallzeiten 315 Albachs 4 Aldus 269 Altiris 36 amerikanischen Instituts der Wirtschaftsprüfern 195 Analyse der Abläufe in K-Fällen 246, 342 Analyse des Business Requirements 114 Analytische QS-Maßnahmen 300 Anbietervorteils 33 Änderungen in der Systemumgebung 41 Änderungsmanagement 352 Anforderungen an das Informationsmanagement 15, 16 Anforderungen an das Projektmanagement 347

368

Index

Anforderungsanalyse 299 Angebotsdruck 4 Angriffe 17 Angriffsmuster 244 Angriffsmuster für Attacken 226 Annäherungen zur Qualitätserhöhung 283 Anschlusstechnik 15 ANSI 195 ANSI/IEEE-Standard 829 298 Ansoff-Matrix 13 Anwendungen der E-Medizin/ Bildverarbeitung 38 Anwendungsdaten 112 Anwendungserlass zur Abgabenordnung 66 AO 64 Appliance 17 Application Programming Interfaces 331 Arbeitsanweisungen 64 Arbeitsaufträge 2 Arbeitsplatz 34, 40, 47 Arbeitsplatzrechner 34 Arbeitsplatzrechnern 194 Archivdaten 346, 353, 355 Archive 1, 258 ArchiveLink 256 archivierten Daten 264 archivierten Informationen 258 Archivierung 25, 38, 47, 49, 82, 149, 226, 257–265, 269, 273 Archivierung von Vektorgrafiken 273 Archivierungsbasierte Klassifizierung 178 Archivierungsdauer 47 Archivierungsebene 135 Archivierungsformatanforderungen 266 Archivierungsformate 266 Archivierungshard- und software 30 Archivierungshardware 48 Archivierungskonzept 266 Archivierungsphase 24, 30, 45–49, 52, 56 Archivierungsprozess 264 archivierungsrelevante Buchführungsund Datenschutzpflichten 261 Archivierungssoftware 47 Archivierungstechnik 49 Archivierungsvorschriften 52 Archivierungszeitraum 23 Archivierungszwecke 270 Archivmedien 259

Archivordner 264 Archivserver 255 Archivzwecke 271 Array 17, 215, 339 Array-Informationen 295 ASCII-EPS 272 Assignment zu Agents 291 Association for Information and Image Management International 276 Association for Suppliers of Printing, Publishing and Converting Technologies 276 asymmetrischen Kryptosystems 243 attackierenden IP-Adresse 199 Attacks 17 Attributausprägungen der Archivierungsphase 46 Attributausprägungen der Bewahrungsphase 43 Attributausprägungen der Erstellungsphase 37 Attributausprägungen der Verdichtungs-/ Nutzungsphase 41 Audio-On-Demand 39 Audit-Checkliste des Bundes der Deutschen Revisoren 314 Auditing 196 Audit-Trail 93 auf SATA-Platten 27 Aufbau von Wettbewerbsvorteilen 33 Aufbewahrung der Unterlagen 63 Aufbewahrungsfrist 24, 47, 258 Aufbewahrungspflicht 24, 64, 264 Aufbewahrungsräumen 193 Aufbewahrungs-Restzeit 57 Aufgabe des Backups 237 Aufgabe des Information Lifecycle Management 58 Aufgabe des Qualitätsmanagements 31 Ausfalleffektanalyse 313 Ausfallkosten 314 Ausfallzeiten 117 Ausfallzeiten minimiert 27 Auskunftsklassifizierung 179 Auslastungsgrenze der Speicherkapazität 262 Auslastungsoptimierung 34, 35, 40, 41, 45, 48, 49 Auslastungsoptimierung in der Bewahrungsphase 45 Ausschreibungsunterlagen 355

Index

Austauschformat 272 Auswahl des Archivsystems 259 Auswertbarkeit personenbezogener Daten 78 Auswertung von Archivdaten 264 Auszeichnungssprache 267 Authentifizierung 196 Authentisierungsserver 338 Authentizität der Daten 243 Auto Fix Prozeduren 291 automatischer Softwareupdates 36 automatisiert 40 automatisierte Business Intelligence Prozesse 49 automatisierte Datensicherung 248, 249 Automatisierung der Administration 21 Automatisierung von Prozessen 354 Autorisierung 40, 196 Availability 18

B Backup 36, 176, 193, 196, 226, 236–238, 255, 256 Backup and Data protection based on Hot Site – Server displacement 250 Backup and Data security without a Hot Site 247 Backup and Protection by Hot Site – Server out of Pool 248 Backup Medium Band 241 Backup Medium Festplatte 240 Backup- und Recovery Strategien 18 Backup und Recovery von IT-Anwendungen 257 Backup und Restore 257 Backup-Applikationen 243 Backup-Architekturen 242 Backup-Daten 241 Backup-Klassen 238, 240 Backuplösungen 237 Backup-Medien 237, 241 Backup-Medium 239 Backup-Prozess 191 Backups 243, 246, 343 Backup-Sicherheit 236 Backup-Strategien 237 Backup-Systemen 314 Backup-to-Disk 253 Backup-to-Tape 247–250 BaFin 105, 322

369

Balance zwischen Storage-Ressourcen und Sicherung der Daten 238 Band-Backups 240, 254 Bändern 255 Bandlaufwerk 215, 247–250, 257 Bandspeicher 257 Bandspeicher von IBM 257 Bandspeichersysteme 257 Bandsysteme 241 Basel I 87 Basel II 19, 60, 87, 88, 194 Baseler Akkord 87 Baseler Ausschusses für Bankenaufsicht 60, 87 Baseline TIFF 269 Baseline-Einschränkungen 270 Baseline-Spezifikationen 270 Basis-Installation 289 Basis-Installation der Neusysteme 289 Basisprojektplan 364 Basis-Sicherheitscheck 217 Batch-Anwendungen 32 BDSG 79 Bedrohungsanalyse 226 Bedürfnisse der Unternehmenssteuerung 2 Befolgung nationaler und internationaler Rechtsvorschriften 59 Belege für Buchungen 64 Benutzerautorisierung 35, 43, 46, 49 Benutzerrolle 200 Berechtigungsverwaltung für Benutzerkonten und Systemkommandos 328 Bereich Business Intelligence 2 Bereitschaft 56 Bereitstellung (hochverfügbarer) Serversysteme 36 Berichtswesen 300, 352, 363, 364 Beschaffen, Verarbeiten und Speichern von Informationen 119 Beschreibung der Bedeutung von Information 3 best practice 19, 225, 277, 286, 287, 347 best practice-Lösungen 235 Bestimmungen des Bundesdatenschutzgesetzes hinsichtlich der Datenhaltung, Weitergabe und Aufbewahrung für seinen Geltungsbereich. 80 Best-Praxis-Erfahrungen 146

370

Index

Betriebsführung 324 Betriebsnebenzeiten 55 Betriebsprüfungen 263 Betriebssystem 38 Betriebssystem mit dem höchsten Wachstum 38 Betriebssystemobjekt 201 betriebswirtschaftliche Definition der Produktionsfaktoren 7 betriebswirtschaftlichen Ansatz des Produktlebenszykluses 13 betriebswirtschaftlichen Definitionen für Produkt, Produktionsfaktor und Markt 6 Betriebszeit 32, 55 Bewahrungsphase 24, 29, 43, 45, 46, 52 Beweismittel bei der Dokumentation betriebswichtiger Vorgänge 261 beweisrechtlichen Positionierung 262 Bewusstsein für Qualitätssicherung 280, 311 BGB 60, 79, 105, 313 BI 2, 19 BI-Anforderungen 2 BI-Architektur 2 Bilddaten 269 Bildung von Storageklassen 175 Billing 28 Bindende europäische (Rechts-) Vorschriften 87 Bindende internationale (US-amerikanische) (Rechts-) Vorschriften 91 BI-Sicht 2 BI-Systemarchitektur 2 BITKOM 112, 149, 150 BITKOM-Prozessmodell 149 Bitmap 271 Blind-Exchange-Fähigkeit 276 Blockchiffre 242 Blowfish 196 BMI-KBSt 318 BMP 271 Boehm 313 Boston Consulting Group Portfolio 12 Bounding-Box 273 BPM 2 BPO 138 BrightStor SRM 331 Brühwiler 313 Brute-Force-Angriffe 242 BS 15000 235, 285

BS 7799 218, 223, 224, 233 BSI 8, 245, 276, 277, 327, 331 BSI-IT-Grundschutz 217, 314 BSI-Sicherheitsstandards 39 BSI-Standard 100-1 217, 232 BSI-Standard 100-2 217 Buchführungspflicht 61, 62 Buchführungspflicht des Kaufmanns 61 Buchungsbelege 64 Budgetklarheit 19 Bundesagentur für Arbeit 311 Bundesamts für Sicherheit in der Informationstechnik 333 Bundesdatenschutzgesetz 8, 60, 78 Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. 149 Bundesversicherungsamt 105, 322 bürgerlichen Gesetzbuches 60 Burghard 313, 316 Bürokratie-Ansatz 4 Business Alignment 323 Business Continuity 18, 40, 45, 48, 97 Business Continuity in ILMModellen 257 Business Continuity Management 42, 46, 49 Business Continuity-Planung 245 Business Intelligence 2 Business Intelligence Lösung 36, 40 Business Intelligence Prozesse 35, 43 Business Intelligence Systemen 19 Business Management 29, 325 Business Performance Data 173 Business Performance Management 2 Business Process 111 Business Process Outsourcing 138 Business Recovery-Plänen 246 Business Transaction based Klassifizierung 180 Business- und TechnologieFramework 17 Business-Process-Anforderungen 173 Busniess Continuity Plan 185 Bypassed 215

C California Database Protection Act 93 Campus 202, 226 Capability Maturity Model 317

Index

Capability Maturity Model Integration 317 Carrier-Backbone-Netze 203 Carter 254 CAS 191, 237 Cash Cows 13 CCITT 270 CCTA 235 CDP 186, 201, 338 Center of Excellences 294 Certified Information System Auditor 235 Change Management 49, 289, 290 Change Management Prozess 46, 49 Change Request 352 Channel Extension-Technologie 256 Chaos-Paradigma 3 Charakter der Information in Produktion und Dienstleistung 5 Charette 313 Chiffreschlüssel 17 chiffrieren 243 Chipkartentechnologie 39 CIFS 136, 340 CISA 235, 277 CISA-Ansatz 314 CISA-Audit 235 Cisco 188, 328 Cisco Systems 203 Client-Online-Backup 53 Clive Gold 255 Clone Platten 18 Cloning 26 Cluster 254, 256, 343 Cluster-Softwareeinsatz 40, 45, 48 Clustersystem 26, 36 CMM 317 CMM/CMMI 317 CMMI 317 COBIT 19, 60, 100, 220, 221, 276, 314 COBIT Framework 100, 223 Code of Practice for Information Security Management 61 Committee of Sponsoring Organizations of the Treadway Commission 60, 101 Compliance 19, 43, 59–61, 64, 93, 95, 196 Compliance Anforderungen 49 Compliance/Datensicherheit 238 Compliance-Daten 237 Complianceforderung 25

371

Compliance-Projekt 59 Compliance-Rechtsvorgaben 61 Compliane 258 CompuServe Inc 271 Computer Associates 188 Computer Crime and Security Survey 2005 236 Computer Security Institute 236 Concentrator 199 Config Guide 294 Configuration Management 42, 46, 49 Content Addressed Storage 191, 237 Content Adressable Storage 52 Content Adressable Storage Magnetplattensysteme 47 Content Filter 199 Content-Management 151 Contentserver für SAP 256 contingency-Plan 247 Continous-Data-Protection 201 Continuance- und Disaster RecoverySysteme 245 Control Objectives for Information and Related Technology 19, 60, 100, 220, 314 Controlling 359 Corporate Governance 59, 101 Corsten 4 COSO 60, 100, 101 COSO Report, 332 CRC-Prüfverfahren 196 Critical Data 173 CRM 1, 34, 36, 40, 52, 153 CRM-Systems 42 Crosby 284 Crosby TQM 284 CSI 236 Customer Care 28 Customer Relationship Management 1, 153 Cyritrix 255

D DAS 197 Das Vier-Felder-Portfolio 12 Data Collection Policies 291 Data Lifecycle 111 Data Lifecycle Modell 54 data loss 185, 240, 279 Data Protection Events 182

372

Index

Data Protection InitiativeKlassifizierung 182 Data Protection Window 182 Data Retention Policies 291 Data Warehouse 2, 245 Dataquest 314 Data-Warehouse-Systeme und Supply Chain Management 1 Datenarchivierungssystem 264, 265 Daten-Backup 239 Datenbank 189, 238 Datenbestände von Unternehmen 1 Daten-Cloning 40, 45, 48 Datendiebstahls 194 Datenerstellung in 2006 37 Datenhaltungssoftware 103 Datenhaltungssysteme 264 Datenintegrität 197 Daten-Integrität 196 Datenintegrität von Speichernetzwerken 257 Datenklassen 353 Datenklassifizierung 171, 176, 189, 237, 239 Datenklau 226 Datenkompremierung 200 Daten-Lebenszyklus-Modell nach Moore 55 Datenlöschung 237 Datenmanagementanbieter 17 Datenmanagementfunktionen 176 Datenmissbrauchs 194 Datenreduktion 16 Datenreplikation 176 Datenschutz 35, 43, 46, 49, 78 Datensicherheit 35, 43, 46, 49, 78, 194, 264 Datensicherheit für BackupVorgänge 241 Datensicherheitskonzept 239 Datensicherung 117, 149, 197, 261 Datensicherungsstrategien 26 Datensicherungsumgebungen 242 Datensicherungsverfahren 29 Datenspeicher vernetzen 195 Datenspeicherinfrastrukturen 198 Datenspeichern 239 Datenspeicherung 237 Datenspiegelung 257 Datenverlust 46, 239 Datenverlust ausgeschlossen 27

Datenverwaltungs-DienstleistungenKlassifizierung 182 Datenvolumen 41 datenwertorientierte Datenhaltung 46, 49 Datums-Klassifizierung 183 DB2 257 Decapsulation 203 Decision Support 38 Decru Lifetime Key Management 17 dedizierten Langzeitspeichern 256 Deep Archive 52 Default-VLAN 338 definierten Aufbewahrungszeiten 50 Definition der Aufgaben für die Entwickler aus QS 301 Definition der Projektziele 353 Definition der Sicherheitspolitik 224 Definition des Umfangs des ISMS 224 Definitionen 8 Degeneration des Produktes 10 Delivery Management 359 Delivery Managern 359 Dell 255 dem IT-GrundschutzSchichtenmodell 232 Demacro 313 DeMarco 316 Deming 281 Deming-Modell 281 Deming-Zyklus 281 Denial of Service 226 Denial-of-Service-Attacken 226 Department of Defense Records Management Program 103 Dependency Management 331 DES 196 des Informations-Lebenszyklus 53 des ITIL Service Managements 46 Desaster Recovery Gründen 27 Desaster-Fall 185, 249, 253, 279 Desaster-Rechenzentren 27 Designänderungen 9 Determinismus-Paradigma 3 Deutsche Post IT-Solution 115 Deutsche Post World net 115 Developer Kits 17 dezentralen Datenspeicherung 217 dezentraler Datenhaltung 194 Diederich 6 Dienstleistungsgesellschaft 15

Index

Dienstleistungs-Klassifizierung 183 Dienstleistungsmanagement 281, 285 differentialer Momentaufnahmen 186 Digital Security Anwendungen 39 digitale Krankenakte 38 digitale Sicherheit 40 digitale Signatur 39, 275 digitale Unterlage 261, 263 digitalen Dokumente 258 digitalen Signaturverfahren 265 digitaler Security 39 digitaler Zertifikate 243 digitales Abbild 152 DIN 25424 313 DIN 25448 313 DIN 69901 313, 316 DIN/ISO 9000 313 Direct Attached Storage 197 direkten Remote-Zugriff 200 Disaster Recovery 97, 226, 244, 245, 256, 257, 342, 355 Disaster Recovery im Rahmen ILM 245 Disaster Recovery-Klassifizierung 185 Disaster Recovery-Konzept 256 Disaster Recovery-Planung 246, 343 Disaster Recovery-Systeme 245 Disaster Tier 0 247 Disaster Tier 1 247 Disaster Tier 2 248 Disaster Tier 3 250 Disaster Tier 4 251 Disaster Tier 5 251 Disaster Tier 6 252 Disaster Tier 7 253 Disaster Tier 8 254 Disaster-Recovery/BusinessContinuity 315 Disaster-Recovery-Case 244 Disaster-Recovery-Lösung 244 Discretionary Access Control 200 Disk 17 Disk Arrays 215, 331 Disk-Libraries 52 Disksubsystem 215 Disposition über Elementfaktoren 3 Distributionspolitik 12 DLM Konzeptes 2 DMS 151 DMTF 148 DMX 52 Document Structuring Conventions 273

373

DoD 103 Dogs 13, 57 Dok-Importer 256 Dokumentation der SystemKonfigurationen 246, 343 Dokumentation und Tracking der Bänder 246, 343 Dokumentation, Einführung und Abnahme 291 Dokumentationen 280 Dokumente eines Unternehmens 257 dokumentenechte Langzeitspeicherung 49 dokumentenechte Wiederherstellung 49 dokumentenechten Aufbewahrung der Dokumente zum Geschäftsvorfall 63 Dokumentenformate 255 Dokumentenmanagement 151 Dorofee 313 DoS-Attacken 197, 226 DPW 182 DR 279 drahtlosen Zugang 202 DRBC-Leitfaden 315 DR-Fall’s 245 DR-Lösung 256 DR-Site 246, 279 DS 38 DSC 273 DSC-Kommentare 273 DSL-Zugänge 53 DTI 332 Durchführung der Ausschreibung 355 Durchführung der Migration 289 Durchführung und Dokumentation 302 Duty-Cycle 240 DV-gestützten Buchführungssystems 73 Dynamische Klassifizierungskonzepte 189 dynamischen Speicherprovisionierung 216 dynamisches Multi-Pathing 257

E EAP 203 Early Adopters 9 Ebenen der Virtualisierung 128 ECC 40, 45, 48 ECM 151 Economies of Scale 139

374

Index

Edge Label Switch Router 203 Edge Switch Access Control List 203 EDIFACT 331 EDS 153, 191 EDV 15 E-Finance Anwendungen 38 EFQM 285, 287 EFQM-Modell 285 EFQM-Vorzüglichkeits-Modell 286 EGA 148 Egress Router 203 Eigenkapitalausstattung 87 Einbrüche ins Firmennetz 226 Einbruchversuch in ein System 199 eindeutige Handlungsempfehlungen 4 Eindringlings-Warnsystem 193 eines Information Lifecycle Management 60 Einführung eines geschäftsorientierten Informations-Managements und des Information Lifecycle Managements 345 Einführung jedes ILM-Konzeptes 118 Einhaltung der Compliance Anforderungen 19 Einhaltung der Compliance der Datenhaltung 354 Einhaltung der gesetzeskonformen Aufbewahrungsfristen 264 Einhaltung der vereinbarten Meilensteine 350 Einsatzszenarien 27 Einsatzzweck einer Firewall 199 Einsparungen 16 Einzelabschlüsse 64 Electronic Banking 38 Electronic document file format for long-term preservation 274 Electronic Signatures in Global and National Commerce Act 60, 99 elektronische Archive 259, 265 elektronische Archivierung 151 elektronische Dokumente 260 elektronische Erklärungen 261 elektronische Rechnung 261 elektronische Repräsentationen papierner Geschäftsdokumente und Belege 260 elektronische Signaturverfahren 265 elektronische Unterschrift 243 elektronischer Informationsträger 265

elementarer Katastrophen 27 ELSR 203 E-Mail 2, 24, 39, 103, 112, 261–263 E-Mail an die Mitarbeiter 2 E-Mail Archivierung 64 E-Mail-Accounts 3 E-Mail-Anwendungen 189, 239 E-Mail-Policy 64 E-Mail-Server 135 EMC 187, 188, 193, 255, 256, 330, 331 EMC Centera 256 EMC2 40, 45, 48, 359 EMC2 CENTERA 52 EMC2 CLARiiON 52 EMC2 TimeFinder 52 empfangenen Handelsbriefe 64 Encapsulated Postscript 272 End-to-Site-VPN 199 Engenio 188 Enron 19 ENRON 59, 101 Enterprise Content Management 151, 237 Enterprise Klasse 35, 41, 45, 49, 52 Enterprise Resource Planning 153 Enterprise-Content-Management 258 Entscheidungsgremium 350 Entscheidungsprotokolle 2 Entscheidungsträger 119 Entscheidungsunterstützung 2, 38 Entwicklung der Datenerzeugung 38 Entwicklung der Datenerzeugung und -speicherung 38 Entwicklung der Informationsspeicherung 16 Entwicklung des digitalen Speicherbedarfs 38 Entwicklung des Speicherbedarfs 39, 50 Entwicklungsbegleitende Qualitätssicherung 300 Entwicklungsparadigma 3 Entwicklungsschritte der IT 21 EPS 270, 272, 273, 275 EPS-Daten 272 EPSI 273 Erfassung unstrukturierter Daten 24 Erfassungsphase 35 erhöhter Security-Anforderungen 202 Erkennen eines Einbruchsversuches 199 Erlei 3 Eröffnungsbilanzen 64

Index

ERP 1, 36, 153 ERP-System 26, 34, 40, 42, 52 Erstellung 24, 52 Erstellungsphase 28, 33, 34, 36, 56 Erstellungszeitpunkt 24 ersten drei InformationslebenszyklusPhasen 43 erweiterten Zugriffssteuerung 201 ESF 332 E-SIGN 60, 99 E-SIGN Act 99 Essential Data 173 ETB 138 EU-Richtlinie 19 europäische (Rechts-) Vorschriften 60 European Transaction Bank 138 Eventzyklen 45, 48 Exabytes 37 Excel-Tabellen 2 existierenden Bedrohungsmuster 226 ext2 201 ext3 201 Extensible Access Method 187 Extensible Authentication Protocol 203 eXtensible Markup Language 268 externe Bandarchive 244 externe Prozessinformationen 4 externe Speichermedien 26 externer Speichersubsysteme 16 externes Event Logging 329

F Fabric 215, 256 Fabric-Umgebung 215 facto-Standard im Bereich der Archivierung 235 faktortheoretischen Ansatz 3 Falsch verstandener Zwang zur Verwendung von Standardsystemen 323 falsche Bilanzen 19 falsche Kopie 25 Fälschungssicherheit 265 FC 195, 197, 198 FC-Festplatten 191 FC-GS-4 339 FCIP 197 FC-Laufwerke 240 FC-Platten 240 FC-Protokoll 197

375

FC-SANs 195 FC-Schnittstelle 240 FC-SP 195 FC-Switch 216 FC-Technik 191 FC-Verkabelung 201 FDA 94, 95 Federal Employee Compensation Act 92 Federal Rules of Civil Procedure 60, 98 Federal Trade Commission 97 FedEx 115 Feedbackrunden 365 Fernando 254 Festlegung der Verantwortungsbereiche 291 Festplatte 38, 239, 241, 257 Festplatte des Notebooks 3 Festplattenkapazität 16 Fibre Channel 195, 198, 340 Fibre Channel FCP 215 Fibre Channel Generic Services 4 339 Fibre-Channel-Protokoll 197 Fibre-Channel-spezifische SecurityProtokoll 195 Fibre-Channel-Switches 214 File-System-Archivierung 189 Financial Management 349 Financial Services Modernization Act 97 Finanzdaten 2 Finanzinstituten 15 Firewall 193, 194, 198, 199, 325 Firewalltechnologie 199 Firmware 216 Fixed Content 46, 49 Fixed Content Anwendungen 38 Fixed Content Archivierungs- und Dearchivierungssoftware. 48 FlexFrame 340 Flooding 226 Folgen einer Verletzung der Archivierungspflicht 264 Food and Drug Administration 60, 94 formatiertem Text 272 Forrester 335 Fragebogenprozess 286 FRCP 98 FreeBSD 201 freies Format 266 FTC 97 FTC Safeguard Rule 98

376

Index

FTP-Server-Prozess 200 führenden Speichersystemanbietern 3 Führung der Handelsbücher 62 Fujitsu 254 Fujitsu Triole-Strategie 340 Fünf-Punkte Reifewaage 286

G gängigen Sicherheitsstandards 200 ganzen Seitenlayouts 272 GAO Standards 332 garantierte Bandbreiten 200 garantierte Wiederherstellzeit 239 Gartner 335 Gartner Studie 333 GB 15 GDPdU 261, 263 GeBüV 265 Geeignete Aufstellung von Archivesystemen 259 Geeignete Lagerung von Archivesystemen 259 Gefährdungskatalog des Bundesamt für Sicherheit in der Informationstechnik 226 Gefängnis 19 geheimen Schlüssel 243 General Security Requirements 217 Generationenmodell 177 Generische Klassifizierungsansätze 177 genormte, integrierte Verschlüsselungslösungen 17 Geo-Caching 38 Geographical Information Systems 38 Georgia Institute of Technology 315 geringe Wertschätzung der eigenen Daten 193 geringer Datenverlust 249 Gernerell Security Requirements 276 Gesamtprojektplan 351 Geschäft mit Storage 193 geschäftsbezogene Dokumente 30 Geschäftsfeldklassifizierung 185 Geschäftsgeheimnisse 80 Geschäftskontinuität 245 Geschäftskorrespondenz 262, 263 geschäftskritischen Informationen 18 geschäftskritisches OLTP-System 40 geschäftsvorfallbezogener kaufmännisch relevanter Dokumente 23

geschäftsvorfallrelevanter Informationen 49 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich 314 Gesetz zur Modernisierung des Gesundheitssystems 60, 84 Gesetze 261 Gesetze und Richtlinien für die Datensicherung 261 Gesetzgeber 19 Gesetzgebungen 50 gesetzlich zwingenden Dokumentation von Geschäftsvorfällen 263 gesetzliche Auflagen bezüglich des Datenschutzes 194 gesetzlichen Anforderungen des Datenschutzes 326 gesetzlichen Grundlagen im Kontext des Risikomanagement 313 gespiegelte Systeme 41 Gestaltung der IT-Services 19 gesunkene Wiederverwendungswahrscheinlichkeit 45 gesunkenen Informationswert 45 Gewährleistung der Compliance 40, 47 Gewährleistung direkter Zugreifbarkeit 41 Gewährleistungsfristen 23 GGF 148 GIF 270, 271 GLB 97 Global Sourcing 31 GMP 89 GNOME 201 GoB 67, 105, 322 GoBS 72, 105, 261, 263, 322 Good Manufacturing Practice 60, 89 Grad der Compliance der Unternehmens-IT 19 Grads an Datensicherheit 239 Gramm-Leach-Bliley 198 Gramm-Leach-Bliley Act 60, 97 Greenfield Approach 177 Grenzen einzelner Storage-Systeme 330 Grid 340 Grid für SAP-Umgebungen 340 Grundlage der Portfolio Analyse der Informationen eines Unternehmens 13 Grundlagen des Risikomanagementprozesses 313

Index

Grundmodell des Produktlebenszykluses 9, 10 Grundsätze ordnungsgemäßer Buchführung 67, 263 Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme 72, 261 Grundsätze zum Datenzugriff und zur Prüfbarkeit originär digitaler Unterlagen 261 Grundzüge ordentlicher Buchführung 63 günstigere Medien 29 Gutenberg 3, 4

H Hackerangriffe 194 Haftung der Hersteller 279 Haftungsfolge 261 Haftungsrisiken 280, 311 Handels- und Steuerrechts 263 Handelsbücher 64 Handelsgesetzbuch 61, 261 handelsrechtliche und steuerrechtliche Grundsätze 263 Handelsverkehr zwischen Kaufleuten 261 Hardwareinfrastruktur 27, 34, 40, 48 Hardwareinfrastruktureffizienz 36, 43, 46, 49 Hard-Zoning 214 Hash-Algorithmus 196 Hash-Wert 243 Haupterfolg des Produktportfolios 13 HDAs 26 HDS 52, 256, 257, 359 Health Insurance Portability and Accountability Act 60, 95 Hersteller 17 Herstellerunabhängigkeit 266 Hewlett Packard 331, 359 HGB 47, 60, 61, 64, 105, 322 Hierarchical Storage Management 149, 177, 237 Hierarchisches Storage Management 189 High automated, business-integrierte Solution – Server exklusiv/shared 253 Hijecking von Netz-Verbindungen 226 hinreichend Server- und Speichersystemkapazität 41 HIPAA 60, 95, 96, 198

377

Hitachi 187, 331 Hitachi Data Systems 188, 256, 359 Hoax 226 hochausfallsicheren Produktivsysteme 27 Hochperformante Speicheranwendungen 52 Hochproduktivdaten 346, 353, 355 Hochsicherheitssystemen 200 hochverfügbare Server-(Cluster) 45, 49 hochverfügbaren Archivsystemen 355 hochverfügbaren Speichernetzwerken 257 hochverfügbaren und abgesicherten Netzwerkinfrastruktur 48 hochverfügbarer Speichersysteme 36 hochverfügbares, skalierbares SAN 256 hohe Bedeutung der Datenverfügbarkeit 240 hohe Netz-Verfügbarkeit 239 hohe Performance 41 hohe Skalierbarkeit des Gesamtsystems 255 hohe Verfügbarkeit 26 hoher Informationswert für das Geschäft des Unternehmens 56 homogenes Netzwerk 277 Horva’th 313 Host Connectivity 354 Host-Agenten 289 Hosts 199 Hostsystemen 289 Hot-Backup-Modus 252 Hot-Site 245, 248 HP 187, 188, 327, 331, 359 HP Open-View 327 HP-OpenView 291, 315 HP-UX 121, 200 HSM 177, 189, 256 HTML 267–269 HTTP 336, 340 http/Soap 255 Hypertext Markup Language 268

I IBAG 332 IBM 121, 187, 188, 256, 257, 327, 330, 331, 359 IBM DS8xxx 52 identischen remote Systemen 27 IDS 193, 194, 199

378

Index

IDW 105 IEEE Adresse 215 IETF 148, 203 IFAC 332 IIA 332 IKS 73 ILM 1, 134, 153, 177, 190, 193, 199, 217, 239, 245, 257, 261, 276, 277, 311, 312, 323, 324, 327, 331, 332 ILM als Modell mit dem Fokus Speicherung der Information 151, 154 ILM als Prozessmodell 150 ILM aus Sicht des Projektmanagements 159 ILM-Archivierungs- und tiered storage Lösung 359 ILM-Automation 147 ILM-aware-Anwendungen 178 ILM-Einführung 318 ILM-Einführungskonzeptes 280 ILM-IT-Gesamtsystem 289 ILM-konform 246, 343 ILM-konforme Backup-Umgebung 237 ILM-Konzept 2, 105, 113, 141, 237, 238, 258, 277, 280, 311, 326 ILM-Lösung 237 ILM-Modell 2, 107 ILM-Projekt 61, 172, 289, 311–313, 316, 347 ILM-Strategie 238 ILM-Umfeld 233 ILM-Umgebung 61 Implementierung der ArchivierungsGeschäftsprozesse 53 Implementierung eines IT-Grundschutzes 19 Implementierung und Test 290 Implementierung von Information Management 345 Implementierungsleistungen 290 Implementierungsservice 291 Incident-Management 46, 49 individuelle Definition von Daten-, Storage- und Backup-Klassen 238 Industrial Engineering 4 industrielle Produktionsprozess 4 Industrieökonomik 3 Industriestandard für die Verwaltung von Disk Arrays und Storage Switches 331 Informatik 15

Information als Produktionsfaktor 5 Information als Verbrauchsfaktor 4 Information Lifecycle 10, 13, 15, 111 Information Lifecycle als speziellen Produktlebenszyklus der Information 20 Information Lifecycle Management 1, 10, 15, 53, 56, 59, 345 Information Lifecycle Management als phasenbezogenen Strategien-Mix 13 Information Lifecycle Phasen 52 Information Lifecycle und IT-Systeme 24 Information Lifestyle Management 177 Information Management 13, 16, 19, 20, 56, 58 Information Retention Laws 60, 91 Information Security Management Software 333 Information Security Management System 223, 332, 333 Information Service 120 Information Systems Audit and Control Associacion 220 Information System-Strategie 124, 156, 157 Information Technology-Strategie 124 Informationen aus Crem-Systemen 26 Information-Lifecycle-ManagementStrategie 238 Information-Management-Strategie 124 Informations Lebenszyklus 20, 22, 23, 29, 52, 53, 56, 58 Informationsgesellschaft 24 Informationsinfrastruktur 21 Informationslebenszyklusphasen 41 Informations-Lebenszyklus-StrategieMix 30 InformationsmanagementDienstleistungen-Klassifizierung 185 Informationsobjekten 2 Informations-Portfolios 58 Informations-Produktlebenszyklus 8 Informationssicherheit 332 InformationssicherheitsManagementsystems 218 Informationstechnologie 20 Informationsverbrechen 194 Informationswachstum 16 Informationswert im Lebenszyklus 25 Informationswert-Anpassung 43, 46, 49 Informationswert-AufbewahrungszeitMatrix 13, 53, 54, 56, 58

Index

Informations-Zeit-Diagramm 22 Infrastrukturanpassungen 16 Infrastruktureffizienz 35, 40, 45 Infrastruktur-Management-Tools 329 Ingress Router 203 initiale Konfiguration 289 inkompatible Managementsysteme 17 Innovatoren 9 Input- und Output-Management 151 Input-Output-System 3 Inrange 256 Installation der Softwarepakete 289 Installation Neusysteme 289 Installationsreferenzen 17 Instant Messaging 103 Institut der Wirtschaftsprüfer 105, 322 Integration 17 integrierten Datenmodell 2 Integrität der gespeicherten Informationen 265 Integrität der gespeicherten Informationen von Gesetzes wegen 265 intelligenten Disk-Array 215 Internal Revenue Service 92 international tätigen Konzernunternehmen 15 Internationale Ratingagenturen 88 Internationaler Qualitätsstandard 285 interne Kontrollsystem 73 interner NTP-Server 338 Internet 53, 199, 262, 273 internet Small Computer System Interface 16 Internet-Protokoll 197 Interoperabilität 17 Intrusion Detection System 193, 199 Intrusion Prevention Systeme 199 Inventare 64 Investitionsanträge 2 Investitionsgütermarketing 13 IOPS 238, 240 IP 17, 197 IP Storage 134 IP-Layer-Security 195 IP-Protokoll 197 IP-Protokollbasierten Paketen 199 IPS 199 IPsec 195 IP-Spoofing 226 IRS 92 IRS-Regel 92

379

IS 120, 295 IS (Informations-Service)-Strategie 124 ISACA 221, 235, 331, 332 iSCSI 16, 195, 197, 215, 340 iSCSI-SANs 195 ISMS 223, 232, 332, 333 ISMS-Lösungen 333 ISO 12207 298 ISO 12234-2:2001 269 ISO 15489 103 ISO 15930 274 ISO 15930-6:2003 274 ISO 17799 195, 218, 224, 225, 233, 331, 332 ISO 20000 184, 233, 235, 277, 285, 331, 332, 348, 349 ISO 27000 225 ISO 27001 223, 332 ISO 9000 223, 285 ISO 9001 223, 285, 287, 333, 347 ISO 9001:2000 319 ISO TR 13335 219 ISO/CD 19005-1 274 ISO/IEC 15288 319 ISO/IEC 17799 218, 223, 333 ISO/IEC 27000 223 ISO/IEC 27001 223 ISO/IEC 27004 223 ISO/IEC 27005 223 Isolierung des Storage 202 ISO-Norm 270, 271 ISO-Norm PDF/X 276 ISO-SGML-Norm 268 IT Governance Institute 100 IT Infrastructure Library 235 IT Service Management Forum 61 IT-AmtBw 318 IT-Archivierungsprozesse 53 IT-Entwicklung und ILM 54 ITGI 100 IT-Grundschutz 19, 217, 233, 276, 277, 327 IT-Grundschutzhandbuch 333 IT-Grundschutzmaßnahmenkatalog 327 ITIL 19, 35, 148, 150, 184, 235, 285, 348 ITIL Service Managements 41 ITIL-basierenden Best Practices 325 ITIL-Basis-Prozess 349 ITIL-Basis-ProzessKostenmanagements 349 ITIL-Beschreibungen 235 ITIL-Projekte 349

380

Index

ITIL-Prozessdurchführungen 286 ITIL-Service Managements 36 IT-Infrastructure-Library 19 IT-Infrastruktur 141 IT-Infrastruktur Management 327 IT-Infrastrukturplanung 118 IT-Kosten 120 IT-Management 61 IT-Primärtechnik 41 IT-Risiko-Management 311–315 ITSEC 200, 219 IT-Security-Policy 195 IT-Sekundärtechnik 45 IT-Sicherheitskonzept des BSI 232 IT-Sicherheitsmanagement 217 ITSMF 61, 148 IT-Strategien für das Information Management 20 IT-Strategien für die Archivierungsphase 48 IT-Strategien für die Bewahrungsphase 44 IT-Strategien für die Verdichtungs-/ Nutzungsphase 42 IT-Strategien-Mix 33, 53, 58 IT-Strategien-Mix im InformationsLebenszyklus 31 IT-Strukturanalyse 217 ITU 270

J Jacques Delors 285 Jahresabschlüsse 64 jeweils gültigen Releasestand 34, 40 JFS 201 John W. Thompson 197 Joint Photographic Experts Group 271 Joseph Juran 283 JPEG 271 JPEG 2000 271 Jukeboxen 256 Juran 283 Juran-Modell 283 Juran-Trilogie 283 juristische Grundlagen für ILM 30

K Kapazitätsmanagement Synergien 361 Kapselung 303

Katastrophenfall 194, 244, 245 kaufmännischen Bestätigungsschreiben 261 Kaufwiderständen 9 KDE 201 Kennzahlenermittlung 19 Kerbschnittmuster 10 Kernforderung den Backup- und Wiederherstellprozesses 238 Keyfaktor Security 193 K-Fall 27, 245, 247, 254, 343 K-Fall Schutz 355 K-Fall-Standortes 248 K-Fall-Übungen 246, 342 Kick-Off-Workshop 356 Klartexttunnel 199 Klassen 304 Klassifizierung 182 Klassifizierung der Daten 2 Klassifizierung von Informationsobjekten 2 Klassifizierungskonzepte 171 Klassifizierungsmodelle 238 Klassifizierungsprozesses 265 Klassische Sicherheitskonzepte 198, 202 klassischen Security-Ansätzen 196 KM 287, 302, 347 KM-Plan 309 KM-Tools 300 Kommunikation 12 Kommunikationsmatrix 61 Kommunikationsmustern 199 Kompatibilitäts-Tabellen 291 Komponenten 304 Kompressionsverfahren 269 Konfigurationsdateien 328 Konfigurationsmanagement 287, 347 Konqueror 201 konsequenten Betriebsführung 216 Konsistenz der Geschäftsprozesse des Unternehmens 25 konsolidierte Zielumgebung 289 Konsolidierung 152, 277, 323, 355 Konsolidierung von Bandspeichersystemen 256 Konstruktive QS-Maßnahmen 299 Konsumgütermarketing 13 kontinuierliche Datensicherung 198, 201 kontinuierliche Qualitätssicherung 280, 312 kontinuierlichen Datenschutzes 186

Index

Kontinuierlicher Refresh 177 KonTraG 19, 47, 101, 313, 314 Kontrolle des Änderungsmanagements 308 Kontrolle von Bearbeitungskompetenzen 309 Kontrollinstanz 61 Konverter 258 Konzept für die Kontrolle und Durchsetzung von Zugriffsrechten auf IT-Systeme 203 Konzernabschlüsse 64 Konzernlageberichte 64 Kopie der Produktionsdaten 245 Kosten der Hardwareinfrastruktur der Informationshaltung 26 Kosten der Information im Lebenszyklus 27 Kosten der Information über ihren Lebenszyklus 25 Kosten der Informationsgewinnung 25 Kosten der Prozess-Infrastruktur 26, 28 Kosten der Prozess-Infrastruktur der Informationshaltung 26 Kosten der Software-Infrastruktur 28, 29 Kosten der Software-Infrastruktur der Informationshaltung 26 Kosten im InformationsLebenszyklus 25 Kostenbewusstsein 46, 49 Kosteneffizienz 21 Kosteneinsparungspotenziale 122 Kostengesichtspunkten 3 kostenintensiven Primärtechnik 45 Kostenmanagement 31 Kostenmanagement von Dienstleistungen 31 Kostenminimierung 29 Kostenreduzierung 354 kostensensitives Datenmanagement 1 Kostensteuerung 364 Kostenziele 355 kraft Handelsbrauchs 261 Krcmar 312 Kreditvergaberichtlinien 19 Kreditwesengesetz 60, 86 Krypto-Algorithmus 242 KundenattraktivitätsLieferantenpositions-Portfolio 13 Kundenportfolio 13

381

Kundenstammdaten 23 Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten 43 kurze Wiederanlaufzeit 249

L Label Switch Router 203 Label Switching 203 Lageberichte 64 Lagerhaltung 6 LAN 194, 202, 243 LAN-free Backup/Recovery 256 langfristige Aufbewahrung von Daten 52 langfristige Aufbewahrungsfristen 47 langfristige Speicherung und Aufbewahrung 49 Langzeit-Archivdaten 264 Langzeitarchivierung 270–272, 276 Langzeitarchivierungsformat 272 Langzeitsicherungen 253 Langzeitstabile Formate für Pixelgrafiken 269, 270, 271 Langzeitstabile Formate für Seitenbeschreibung und beliebige Grafiken 273 Langzeitstabile Formate für textbasierte Informationen 267 Langzeitstabile Formate für VektorGrafiken 273 Langzeitstabile Formate für Vektor- und kombinierte Grafiken 272 langzeitstabiles Datenformat 269, 270 LAN-Segmente 336 LAN-Switch 214 Lebenszeit 2 Lebenszyklus 12, 25, 26, 33, 257, 258 Lebenszyklus der Information 22 Lebenszyklus konformer Archivierung von Daten 80 Lebenszykluskonforme Datenspeicherung 354 Lebenszyklusphase 27, 43 Legal Hold Policy 99 Legato 257 Leistungsdimensionen 3 Leistungsergebnis 5 Leistungserstellungsprozess 5, 31, 33 Leistungsportfolio 352 Leistungspotenzial 5 Leistungsziele 355

382

Index

Leitungsortung 38 Lenkungsausschuss 350, 363 Leschke 3 Level der Implementierung von Security-Konzepten 17 Libraries 26 Lieferanten 17 Lieferantenauswahl 355 Lifecycle-Management 341 Limitierung des E-Mail-Accounts 3 Linux 38, 121, 201 Lister 313, 316 Littkeman 316 LKM 17 Load Balancing 256, 257 Logical Unit Number 215 Logical Unit Number-Masking 195 logische Platteneinheit 215 Logische Wiederherstellzeit 55 lokale Ablage 3 Löschen von Daten 237 Lotus Notes 256, 261–264 LSI-Logic 359 LSR 203 LUN 195, 215 LUN Masking 215, 339 LUN Zoning 215 LUN-Binding 215 LUN-Masking 214–216, 338 LUN-Security 215 LUN-Zugangs 216 LUN-Zugriffstabellen 216 LZW-Kompression 270

M MAC 203 MAC-Flooding 226 Macharzina 3 Magnetbandarchivierungen 47 Magnetbandbibliotheken 49, 52 Magnetbänder 38 Magnetbandkassetten 239 Magnetband-Libraries 26 Magnetplatten 38 Magnetplattensysteme 52 Mail 262, 264 Mailbox 261, 264 Mainframe 247, 257, 279 Makro-Viren 226 MAN 202

Managed Security Services 335 Management als Bewältigung von Unsicherheit 3 Management der Anwendungen 327 Management der Kommunikation und des Betriebs 234 Management der Speicher- und Netzkomponenten 216 Management der StorageInfrastruktur 204 Management des Fehlerrisikos 311 Management des kontinuierlichen Geschäftsbetriebs 224 Management Policies 291 Management Schnittstellen 204 Management Storage Infrastruktur 330 Management verteilter IT-Systeme 327 Management von unstrukturierten Daten 171 Managementaufgaben 4 Management-Interface 337 Management-Netz 337 Managementphilosophie für Aufbauqualität und konkurrenzfähige Produktivität 281 Management-Standard für die Qualitätssicherung 333 Managementsysteme für Informationssicherheit 232 Managementsystems 327 Management-System-Standard 223 Management-Zugang 216 Management-Zugangspunkte 205 Mandatory Access Control 200, 203 Mangel an Visibilität 25 Man-in-the-Middle-Attacke 243 Manipulation von Managementparametern 226 MaRisk 88 Marketing 13 Marketing-Mix 13 Marktanteil 12 Marktanteil-Marktwachstums-Matrix 12 Markttransparenz des Informationsmarktes 8 Marktwachstum 12 Maskerade 226 Masking 216 Masterplans 351 Max Weber 4 Maximaler geplanter Datenverlust 56

Index

Maximaler Zeitraum für die logische Wiederherstellung der Anwendungsdaten 32 McData 188 MCI 59, 101 MD5 196 Media-Streaming 238 medienunabhängige Codierung von Textinhalten 269 Medizingeräteverordnung 60, 82 Mehrbenutzersystemen 204 Mercury Interactive Corporation 293 Messung der Storageklassen 177 Metadaten 276 Meta-Datenbasierte Klassifizierung 185 Methode 304 Methode 635 356 MetroCluster 253 Metropolitan Area 202 Metropolitan Area Network 226 Micro- und Flarecodes 53 Microcode Levels 295 Micro-Code-Changes 204 Micro-Server 255 Microsoft 38, 269, 327, 359 Microsoft Office 268 Microsoft Project 2003 364 Microsoft Windows 201, 271 Microsoft Word 269 Midrange Klasse 45, 49 Midrange Magnetplatten(-systeme) 52 Migration 49, 238, 289, 354, 355 Migration der Systeme 289 Migration von Applikationen 289 Migrationsprojekt 279 Migrationsverfahren 360 migriert 35 Mindestanforderungen an das Risikomanagement 88 minimalen Verzögerung 27 Minimierung der Projektrisiken 319 Mirroring 52 Mischkalkulation 177 Missbrauch der Routing-Protokolle 226 Missbrauch von Fernwartungszugängen 226 Mission-Critical Anwendungen 52 Mitarbeiter 194 Mitarbeiterschutz 262 mittelständischen Unternehmen 15 Modell 287, 347, 348

383

modernen Datenspeicherung 1 Modifikation der ARP-Tabellen 243 MOM 291, 315, 327 Monitoring- und Administrationssystems 36 Moore 54, 55, 57 Morrisey 254 Motivation der Belegschaft 280 MPLS 203 MPLS Label Stack 203 MPLS Netzwerkes 203 MPLS Paketen 203 MPLS Tunnel 203 MS Project 2003 351 MSS 335 MSS-Provider 335 Multiliterale Sicherheitsmodelle 200 multiple Zugriffspfade 26 Multiprotocol Label Switching 203 Multi-Tier Information Lifecycle Management Landschaft 53

N Nachvollziehbarkeit der Geschäftsvorfälle 63 NARA 103 NAS 16, 17, 36, 134, 191, 194, 197, 199, 201, 202, 225, 233, 237, 256, 336 NAS-Speichernetze 195 National Archives and Records Administration 103 National Voluntary Laboratory Accreditation Program 220 nationale Rechtsvorschriften 60 nativer ACL-Unterstützung 201 Nautilus 201 Navigationssystemen 38 nearline 47 Nearline Daten 346, 353, 355 Nearline Techniken 43 Netware 121 Network Appliance 188, 236, 239 Network Attached Storage 16, 134, 191, 197, 237 Networked Tiered 162 Netzeingänge des Plattensystems 215 Netzmanagement 327 Netzperformance 327 Netzwerkadministratoren 204 Netzwerkinfrastruktur 36

384

Index

neue digitale Applikationen 38 Neue Institutionsökonomik 3 neuen Datenträger 257 Neun-Felder-Portfolio 13 Neustarts der IT-Services 246 Newsmaster 204 NFS 136, 340 niedrigste Wiederverwendungswahrscheinlichkeit der Daten 47 NIST 332 Non-Compliance 19, 59, 60 Non-Critical Data 173 normalen Zugriffssteuerung 200 Normierung der Geschäftprozesse 354 Notfallkonzept 279 Notfallrechenzentrum 256 Notwendigkeit Manager zu führen 283 Novell Open Enterprise Server 121 NPES 276 Nutzen der einzelnen IT-Services 349 Nutzung 52 Nutzungsphase 24, 27, 29, 40 Nutzungszeitraum 23 NVLAP 220 NV-RAM 216

O OASE 148 OECD 331 OECD Guidelines for the Security of Information Systems and Networks 223 offenem Zugriff 194 offenes Mail-Relay 204 öffentlichen Schlüssel 243 Office-Dokumente 112 OGC 235 Ökonomische Ansätze 3 OLTP 36, 38 OLTP-System 34, 42, 52 online 47 Online Anwendungen 32 Online Backup, 53 Online Banken 38 Online Brokern 38 Online Datenschutzes für Backup und Disaster Recovery 342 Online Techniken 43 Online Transaction Processing 38 Online Versicherungen 38

Online-Datenschutz 239, 246, 254, 342, 343 Online-Langzeitarchiv 191 Online-Mikro-Code-Upgrades 279 Online-Publishing-Systemen 269 Online-Systemen 189 Online-Transaction-BasedProcessing 238 Online-Zugriff auf Storage 237 OO-Systemen 304 Open Source 122 Open Systems Support Matrix 291 Open-Source-Model 331 operationellen Daten 2 operativen Umsetzung der Klassifizierung 190 optimale Auslastung der IT-Infrastruktur 21 Optimale Business Continuity 26 optimale Produktverteilung 12 optimalen Kosten 18 Optimierung der Geschäftsprozesse 347 Optimierung von Arbeitsabläufen 280 Optimierung von Kommunikationsstrukturen 280 Optimierungspotenzial 140, 265 optische Medien 38 Optische Speichermedien 52 Oracle 359 Oracle-Datenbank 257 Organisation der Qualitätssicherung 300 Organisation der Sicherheit 233 organisatorischen und technischen Anforderungen für die Archivierung 265 Originalbild 269 originäre Aufgabe der Geschäftsleitung 3 OSD 187 OSHA 51 OSSTMM 334 Out-of-Band-Management 329, 337 Outsourcing 21 Outsourcing in Form eines Managed Security 335

P Paketfilter 199 Papierarchiv 265 Passwort 244, 328 Passwortschutz 196

Index

Passwortverschlüsselung 328, 329 Path Failover 256, 257 PCIE 332 PDCA Modell 223 PDCA)-Zyklus 316 PDF 273 PDF/A 274, 276 PDF/A-Dateien 276 PDF/X 274–276 PDF/X-3 274 PDF/X-Konformität 276 PDF-Features 274 PDF-Probleme 275 PDF-Viewer 274 Penny 255 performante Datenbankmanagementsysteme 36, 40, 42 Personal-Management 286 Personelle Sicherheit 233 Petabyte 15, 16 Pflege der Kundendatenbasis 28 Pflichtenheftes 355 Phasen des Informationslebenszyklus 30 Phasen des Produktlebenszykluses 11, 12 phasenkonformen MarketingMaßnahmen 9 physikalische Größe 15 physikalischen Fehlern 27 physikalischen Portnummern 214 physikalischen Speichermedien 26 physikalischer Ports 215 Physische und umgebungsbezogene Sicherheit 234 physische Wiederherstellung der Hardwareverfügbarkeit 32 Physische Wiederherstellzeit 55 PIT 251 PKI 195 Plan-Do-Check-Act 316 Planung und Design 290 planungs- und entscheidungsrelevante Informationen 2 Platten 257 Plattenausfällen 279 Plattenspeicher 255, 257 Plattformneutralität 266, 270 plattformübergreifendes Datenformat 270 PM 287, 302, 347 PM07 298

385

PNG 270, 271 point-in-time 251 Point-in-time Copies – Server exclusive/shared 251 Point-in-Time-Replikationen 52 Policy Enforcement 331 Polymorphie 304 Population Ecology Ansatz 3 Port Based Network Access Control 203 Port Zoning 215 Portable Document Format 273 Portable Network Graphics 270 Portfolio 347 Portfolioanalyse 12, 13, 56 Portscanns 199 positiven Deckungsbeitrag 10, 13 Postmaster 204 Postmodernen 3 PostScript 272, 274 Potenzialinformationen 4 potenzielle Angreifer 17 potenzielles Sicherheitsrisiko 327 preiswerte Archivierungstechnik 48 preiswertere Sekundärtechnik 45 PreLife-Umgebungen 33 primäres Backup-Medium 245 Primär-Speichertechnologien 52 Primärtechnik 27, 45, 49 Privacy Laws 60, 93 private Mail 262 Private- und Public-Keys 196 Privatmail 262 PR-Maßnahmen 9 Probabilismus-Paradigma 3 Problem Children 12, 56 Problem Management 46, 49 Produktänderungen 9 produktbegleitende Dienstleistungen 4 Produktdiversifikation 9 Produkthaftung 313 Produktionsfaktor Information 2 Produktionsprogrammplanung 13 produktionswirtschaftlichen Grundmodelle 5 Produktivdaten 264 Produktlebenszyklus 8–10, 13, 47 Produktlebenszyklusmuster 10 Produkt-Markt-Portfolio 13 Produktportfolio 12, 13 Projekt- und ProjektmanagementAnsatz 345

386

Index

Projektänderungsantrag 352 Projektänderungsauftrag 353 Projektänderungsprüfung 353 Projektauftrag 353 Projektbezogene Qualitätssicherung 301 Projekt-Controllings 316 Projektfortschritt 350, 364 Projektgremien 350 Projektinformationswesen 363 Projekt-Kick-Off Meeting 351 Projektlaufzeit 356 Projektmanagement 347 Projektmanagement als Dienstleistung 348 Projektmanagement-Ansätzen 347 Projektmanagement-Meetings 363, 364 Projektmanagement-Team 351 Projektmeeting 363 Projektmeilensteinen 351 Projektorganisation 345 Projektplan 295, 351 Projektspezifische Qualitätsziele 293, 297 Projektsteuerung 364 Projektstrukturierung 362 Projektverlauf 289 Projektziele 354 Proxyserver 199 Prozess der Archivierung 258 Prozessautomation 39 Prozessautomatisierung 255 prozessbasiert automatisch gelöscht 25 Prozessinfrastruktur 27, 35, 45 Prozesskette des ITIL Service Managements 49 prozessuale Kompetenz 46 Prüfmethoden 305 Prüfprotokolle 300 Prüfspezifikationen 300 Prüfstandard PS 880 105, 322 Prüfstellen 104 Prüfung verteilter Software 304 PSP 362 Public Schlüssel 243 Public-Key-Infrastructure 195

Q QM 280 QMH 300 QoS 203 QS 280, 287, 302, 312, 347

QS-Berichtswesen 300, 309 QS-gesicherten Schwenk 279 QS-Plan 289, 298 QS-Plan-Aufbau 295 QS-Planung 289 Qualifier 294 qualifizierter digitaler Signatur 79 Qualität der Information 24 Qualität der Ressourcenauslastung 364 Qualitäts- und Risikomanagements 280, 312 Qualitätsanforderungen an das Produkt im Wirkbetrieb 300 Qualitätsdienstleistungen 280 Qualitätserhöhung 283 Qualitätskontrolle 283 Qualitätskontrollen-Handbuchs 283 Qualitätsmanagement 31, 280, 284 Qualitätsmanagementsystem 89 Qualitätsplanung 283 Qualitätsrat 283 Qualitätsrisiken 298 Qualitätssicherung 279, 285, 287, 311, 347 Qualitätssicherung durch den QSV 302 Qualitätssicherungsgrundsätze 298 Qualitätssicherungsmaßnahmen 279 Qualitätsziele 292 Qualitätsziele an das IT-System 296 Qualitätsziele für Hard- und Software 292 Qualitätsziele für Prozesse 297 Qualitätsziele Projektmanagement 292

R RADIUS 329, 337 Radius-Server 203 RAID-Schutz 26 Randbedingungen 354 Rand-RouterZugriffssicherungslisten 198 Rastergrafiken 272 Rationalismus/Kognitivismus 3 RBAC 204 Reaktionszeit 56 Realisierung von IT-Sicherheitsmaßnahmen 217 Rechner mit Netzwerkschnittstellen 199 Rechnernetzen 204

Index

Rechtliche Anforderungen an die Archivierung 260 Rechtliche Grundlagen 59 Rechtspflichten 261 rechtsrelevante elektronische Erklärungen 261 Rechtssicherheit 262 Rechtsvorschriften 60, 61 Records Management 61, 151, 258 Records Management Application 103 Recovery 176, 239 Recovery Point Objective 182, 187 Recovery Time Objective 182, 187 Redo-Logs 252 Reduktion der Daten 29 Reduktion der Risiken der Non-Compliance 19 reduzierte Verfügbarkeitsanforderung 45, 48 Reduzierung der Abhängigkeiten 301 Referenzdaten 52 Referenzmonitor 200 Regelung der Sicherheit von Informationssystemen und Netzwerken 223 Regelungen der Department of Defense 60 Regelungen des Bundesdatenschutzgesetzes 78 Regelungen des bürgerlichen Gesetzbuches 79 Regelungen zur ordnungsgemäßen Buchführung 60 Reglementierung der Transparenz des Informationsmarktes 8 reguläre Zugriffsrechte 200 Regularien der US-Börsenaufsicht SEC 60 Reifephase 9 ReiserFS 201 rekonstruieren 3 Release Management 34, 36, 40, 42, 45–47, 49 Releasewechsel 3, 36, 42 remote gespiegelten Daten 18 remote Mirroring 48 remote Mirroring Verfahren 40, 45 Remote-Access-VPN 199 Remote-Administration 336 Remote-Systeme 27 Replikation 52, 149

387

Replizierung 237 Reporting 196 Reporting Construct 331 Ressourcen- und KommunikationsRisiken 359 Ressourcen-Management 324 Rest-Aufbewahrungszeit 56 Restore 36 Revisions- und Datensicherheit 263 Revisionsbaumstämmen 205 revisionsgerechte Durchführung aller IT-Aktivitäten 235 Richtlinien 261 Richtlinien zur Qualitätssicherung der Produktionsabläufe und -umgebung 89 Riijndael-Algorithmus 242 Risiken bei der RemoteAdministration 337 Risiken der Non-Compliance 21 Risiko eines Datenverlustes 201 Risikoanalyse 95, 279, 356 Risikoidentifikation 224 Risikomanagement 225, 279, 280, 311–313, 319 Risikomanagement als Teil des Qualitätsmanagements 279, 311 Risikomanagement für die Innovation ILM 313 Risikomanagement im Projektmanagement 316 Risikomanagement im Rahmen des V-Modells 317 Risikomanagement im Rahmen des V-Modell-XT’s 318 Risiko-Management-Gründen 279 Risikomanagement-Modell des Software Engineering Institute 316 Risikomanagement-Modell nach CMM/CMMI 317 Risikominderung 311 Risk Assessment 95 RMA 103 Rohdaten 28 Role Based Access Control 204 Roll-back-Verfahren 294 Röntgenverordnung 60, 83 Root-Bridge 338 Router 243, 328 RPO 182, 187 RSA 193

388

Index

RTO 182, 187 RZ-Infrastruktur 27, 40, 45, 48

S Sabotage 226 Safeguards Rule 97 SAM 277, 326 SAM-Modell 150 SAN 16, 36, 134, 177, 191, 194, 195, 197, 199, 201, 202, 214–216, 225, 233, 237, 256, 336 SAN- und NAS-Switch Managements 336 SAN-Fabric 17, 26, 257 SAN-Infrastruktur 216, 340 SAN-Inseln 257 SAN-Solution-Set 256 SAN-Switche 338 SAN-Zoning 214, 215, 338 SAP 359 Sarbanes Oxley Act 50, 51, 60 Sarbanes-Oxley 19, 198 SAS 186 SATA 240 SATA Platten 49, 240, 253 SATA Technologie 52 Sättigungsphase 9 Sauerland 3 Scalable Vektor Graphics 273 Schlüssel zum IT-RisikoManagement 316 Schlüsselverwaltung 243 Schnittstellen 302 Schutz der unternehmenskritischen Informationen 18 Schutz vor Ausspähung oder Missbrauch 18 Schutz vor einen Eindringen von Außen 193 Schutz vor unbefugtem Zugang 258 Schutzbedarfsfeststellung 217 Schwankungsmuster 10 Scientific Management 4 SCM 1 SCSI 354 SCSI-Festplatten 240 SCSI-Protokoll 215 SE 302 SEC 50, 97, 102, 105, 198, 322 SEC Rule 92 Sechs Sigma Modell 284

Second Study on Digital Data Creation 37 Secondary System- und Speichertechnologie 45 Secure Tape Transport Service 243 Secure-Shell 195 Securities and Exchange Act 102 Securities and Exchange Commission 97 Security 193, 280, 311, 325 Security and Exchange Commission Regeln 92 Security based Klassifizierung 185 Security der Daten 193 Security Descriptor 201 Security Management Tool 331 Security Policy 334 Security Requirements for Cryptographic Modules 220 Security Strategie 244, 257 Security- und User-Policies 262 Security-Empfehlungen 336 Security-Empfehlungen bei Nutzung eines VLAN 337 Security-Empfehlungen bei Nutzung eines zentralen Authentifizierungsservers 337 Security-Instrumenten 202 Security-Konzept 277 Security-Management 205, 217 Security-Management-Plan 198 Security-Management-Planung 205 Security-Maßnahmen 225 Security-Modelle 226 Security-Plan 205 Security-Polcies 277 Security-Requirements 277 Security-Risiko 204 Security-Sicht 205 Segment 12 Segment der Dogs 13 SEI 316 Seitenbeschreibungssprache für Internet-Browser 268 Sekundär-Speichertechnologien 52 Sekundärtechnik 45, 48, 49 Selbstabschätzungsfragebogen 285 Selbstabschätzungsprozess 286 Selbstprüfungen 302 Sensible Data 173 Sequenzieller Datenzugriff 238 Serial Attached SCSI 186

Index

Server 326 Server Access Control List 200 Server- und Speichersystemkapazität 35, 45 serverbezogenen Migrationsaktivitäten 364 Server-Cluster 41 Serverraum 327 Serversysteme 26, 257, 325 Service Desk 49, 56 Service Level Agreement 26, 183, 238 Service Level Management 184 Service Support 40, 45 Service- und Business-Management 324 Servicemanagement 33, 315 Servicemanagementsysteme 28 Service-orientierten Architektur 325 Session-Timeouts 329 SGML 267, 268 SGML-Datei 267 SGML-Software 267 sichere Datensicherung 249 sichere Informationsverbreitung und Informationsaufbewahrung 261 sicheren Betrieb von Speichernetzwerken 257 Sicheres Verschlüsselungsverfahren 242 Sicherheit 17, 194 Sicherheit der Informationsübertragung 196 Sicherheit seiner digitalen Daten 194 Sicherheitsfunktionen 17 Sicherheitskonzepte 194 Sicherheitskopien 239 Sicherheitsmechanismen 40 Sicherheitspolitik 233 Sicherheitsprotokolle 195 Sicherheitsrichtlinie 327, 334 Sicherheits-Software 194 Sicherheitstechniken zum E-Commerce 39 Sicherheitstechnologien 194 Sicherheitsverletzungen 194 Sicherung 193, 194 Sicherung der Datenverfügbarkeit 257 Sicherung des Leistungspotenzials 31 Sichtbarkeit von Festplatten 215 Simulationen 38 Single Point of Failure 246, 343 Site-to-End 199 Site-to-Site 199

389

Skaleneffekte 9 Skalierbarkeit der Installation 294 Skalierung der IT-Infrastruktur 20 Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen 16 Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität 17 SLA 184, 237, 238, 325 SLA-Management 42, 46, 49 SLM 184 SMI-S 331 SMI-S-Standard 331 SMTP-Server 183 SnapManager für SQL-Server 252 SnapMirror 249, 252 Snapshots 18, 40, 45, 48, 52, 186, 201, 202 Snapshot-Technologien 26 SnapVault 249, 251, 252 SNIA 150, 180, 182, 216, 331 SNIA Business Transactions 180 SNIA Stufenmodell 146 SNIA-Roadmap 146 SNIA-Standard 187 SNMP 336, 338 SNMPv1 336 SNMPv2 329, 336 SNMPv3 329, 336 SNMP-Varianten 337 SO/IEC 27003 223 SOA 325 SOC 248, 249 Software Engineering Institute 316, 317 Softwareinfrastruktur 26, 27, 33, 34, 40, 43, 46, 47 Software-Releasewechseln 49 Softwareverteilung 327 Soft-Zoning 214 Solaris 121, 201 Solvabilitätsverordnung 88 SolvV 88 Sonderbedingungen 56 Sonstige Regelungen zur Buchführung 67 SOW 295, 352 SOX 60, 101 Sozialgesetzbuch 60, 80 Spamfilter 262 Spanning Tree 338 SPC 284 Speicherbedarf 15 Speicherebenen 54

390

Index

Speicherindustrie 52, 195 Speicherkapazitäten 265 Speicherkonsolidierungsprojekte 16 Speicherkosten 2 Speichermedien 64, 195 Speichernetz 177, 191, 195, 197, 226 Speichernetzwerke 200, 226, 330 Speichernetzwerk-Virtualisierung 134 Speicherplattformen 346 Speicherpools 216 Speichersegmente 215 Speichersoftware 53 Speichersubsystemen 16 Speichersystem 26, 27, 52, 53 Speichersystemkapazität 49 Speichersystemkonsolidierung 359 Speichertechnologie 18, 41, 49 Speicherung 33, 273 Speichervolumen 1 speziellen Lebenszyklus der Information 13 speziellen Produktlebenszyklus 10 Spezifische Anforderungen an die Prüfung objektorientierter Software 302 Spiegel 186 Spiegelungs- und Business-Continuity Software 53 Spoofing 226 Springersysteme 360 Spyware 226 SRDF 52 SSF 256 SSH 195, 336 SSL-Verbindung 244 SSL-verschlüsselte Verbindungen 243 Stand der Speichertechnik 239 Standard Generalized Markup Language 267 Standardisierte APIs 17 Standardisierungen 280 Standardisierungsgremium 195 Standardsbasierte Klassifizierung 186 Standard-Sicherheitsmaßnahmen 217 Standard-Sicherheitsniveau für IT-Systeme 217, 277 ständige Verfügbarkeit 194 Standish Group 311 Star-Produkte 13 Startphase 350 Stateful Inspections 199

Statement of Work 295 Statische Klassifizierungsmodelle 178 Statusänderungen 23 Statusbericht 351, 365 Statusgespräche 363 Statusinformationen der einzelnen Teilprojekte 364 statuskonforme Kopie 25 Statusmeetings 364 steigenden Dienstleistungsanteil 4 Steigerung der Effizienz der Geschäftsprozesse 19 Steigerung der Infrastruktureffizienz 34, 48 Steigerung des Kapazitätsbedarfes an Festplattenplatz 15 Steuerpflichtige 264 Steuerung eines Unternehmens 2 Steuerungs- und Administrationssoftware 48 Steuerungszielen 225 Storage 151, 173, 185, 237, 249, 326 Storage Area Network 26, 134, 191, 197, 237 Storage Area Networky 16 Storage Controller 215 Storage Infrastruktur 17 Storage Management Initiative Specification 331 Storage Managementkonzept 1 Storage Networking Industry Association 180, 256 Storage Netzwerk 215 Storage Security 195, 197 Storage Switches 331 Storage-Administration 205 Storage-Grid 340, 341 Storage-Grid-Struktur 340 Storage-Herstellern 171 Storage-Infrastruktur 34, 41, 45, 49, 225, 233, 341 Storage-Klassen 237, 238 Storage-Klassifizierungskonzepte 173 Storage-Management 216, 233, 331 Storage-Management-Software 331 Storage-Management-Tools 330 Storage-Migrations 347 Storage-Netz 202, 341 Storage-Netzwerk 199, 203 Storage-on-Demand 216 Storage-Ressourcen-Management 238

Index

Storage-Router 136 Storage-Sicherheit 194 Storage-Systeme 204, 247, 355 StorageTek 172, 256, 257, 359 Storage-Virtualisierung 135 Störungen 46 Störungsfall 40, 45, 48 STP 338 Strategic Business – IT Alignment Models 277, 326 Strategie der Unterstützung der Geschäftsprozesse 45 Strategie für die Informationswert 36 Strategien des Information Management 20 Strategien für die Erstellungsphase 36 Strategien im Marketing-Mix 11 Strategien Mix 20, 33, 36, 39, 43, 46 Strategische Einführungskonzepte ILM 145 strategische Herausforderung an die IT der Gegenwart 19 Strategische ILM-Modelle 150 Strategische IT-Infrastrukturplanung 113 Strategisches Informationsmanagement 126 STTS 243 Suche nach Informationen 2 Sun 257 SUN 121, 359 Sun Microsystems 172, 187, 331 SUN/Storagetek FLX 52 Support Matrix 291 Supported Solutions 256 Supported Solutions Forum 256 SVC Call 294 SVC Mitarbeiter 294 SVG 273 Switche 26, 233, 328 switched SAN Umgebung 354 Symantec 188, 197, 331 Symmetrix 52 synchron oder asynchron zu spiegeln 201 synchrone Sicherung 201 synchrone und asynchrone Abgleiche mit zentralen Systemen 35, 43, 46, 49 Synchrone und asynchrone Spiegelung 52 synchronen Datenspiegelung 257 SyncMirror 253

391

Systemabsturz 117 Systemadministratoren 204 systematische Tests 293 systematisches Management der Informationen 277 Systeme 319 Systementwicklung 234 Systementwurf 299 Systemmanagement 233, 327 Systemmanagementumgebung 40, 45, 47 Systemmigrationen 359 Systems Operation Center 248, 249 systemübergreifenden Seitenbeschreibung 273 Systemverwaltern 326

T TACACS+ 329, 337 Tag Switching 203 Tagged Image File Format 269 Tagged PDF 275 täglichen Arbeitszeit 2 TagmaStore 52 Tape Library 215, 247, 248, 250 Tape-Drives 242 Tapes 17, 241 Target 215 Task Force 220 Taylor 4 TCO-Ansatz 349 TCO-basierten Kosten- und Leistungsverrechnung 349 TCO-Betrachtung 18, 21, 52, 53, 60 TCO-Reduzierung 148 TCSEC 200 technisch und rechtlich sichere Aufbewahrung 261 technische Entwicklung der Speichersysteme 16 technische Lebensdauer des Produktes 9 technischen Sicherheitsmassnahmen 333 technischer Support 17 technisches Projektmanagement 287, 347 technologiegetriebene Speicherkonsolidierung 16 Teilabnahme von Projektmeilensteinen 351 Teilergebnisse 5 Teilziele 355

392

Index

Telecommunication Management Networking 28 Telekommunikationsgesetzes 29 Telekommunikationsunternehmens 29 Telnet 336, 337 Terabyte 15 Terminal Access Controller Access Control System 337 Terminalservice 34 Terminziele 356 Tertiär-Speichertechnologien 52 Test & Acceptance Plan 295 Testansatz Integrationstest 307 Testansatz Klassentest 306 Testansatz Systemtest beziehungsweise fachliche Programmabnahme 308 Testentwurf 298, 306 Testplanung 298 Testprozedurerstellung 299 Tests aller BackupEinrichtungen 246, 343 Testverfahren 298 Testwiederholung 299 Text-Dokumente 25 Theorie der industriellen Dienstleistungen 4 Threshold Values 291 Thumbnail 269 Tier 1 54 Tier 1 Storage 52 Tier 2 54 Tier 2 Storage 52 Tier 3 54 Tier 3 Storage 52 Tierd-Infrastruktur 125 Tierd-Storage-Modells 173 tiered IT-Plattform 35, 45, 48, 49 Tiered Storage 172, 174, 189–191 Tiered Storage Technologien 52 tiered Storagesystemen 36, 43, 46, 49 TIFF 269–272 TIFF Spezifikationen 269 TIFF Technical Notes 270 TIFF/EP 269 TIFF/IT; ISO 12639:2004 269 TIFF-Bildes 269 TIFF-Dateien 269 time to market 31, 124 Tivoli 40, 45, 48, 257, 327 TKG 40, 43 TK-Unternehmen 15, 28

TMN 28 Toll-Collect 311 Total-Qualitäts-System EFQM 285, 287 TQM 284 traditioneller Bandbibliotheken 243 Traffic Engineering- und Quality of Service 203 Transaction Integrity – Server exclusive/shared 251 transaktionssicheres Datenbankmanagement 32 TransPubG 101 Triple-DES 196 Trojanische Pferde 227 Trunk-Negotiation 338 TrustedBSD 201 TrustedSolaris 201 Tunnel 199 Twin location automated, businessintegrierte Solution 254 typischen Lebenszyklus von Informationen 22

U übereilte Systemeinführung 323 Umkopierungsaktivitäten 49 UML-Anwendungsdiagramm 308 UML-Klassendiagramm 308 UML-Komponentendiagramm 308 UML-Spezifikation 302 Umsatzsteuergesetz 60, 66 Umschalten zu Notfallrechenzentren 27 Umsetzung der Projektänderung 353 Unassigned VLAN 338 Unberechtigtes Kopieren der Datenträger 227 unerwarteten Ausfallzeiten 46 ungeplante Produktionsunterbrechung 279 ungesicherter Klartexttunnel 199 Unified Infrastructure Management 325 Unified-Storage-Architektur 153 universellen Standards für ein Qualitätssicherungssystem 285 University of California, Berkeley 37 Unix 38, 200, 233 UNIX 136 Unterhaltungsanwendungen 39 Unterlagen zum SVC-Prozess 294 Unternehmenskennzahlen 19

Index

unternehmenskritischen Geschäftsprozesse 280, 311 Unternehmenszahlen 19 unterschiedliche Stati der auftragsbezogenen Informationen 23 unterschiedlichen Strategien im Marketing Mix 12 Unterschriftenregelung 79 unvollkommenen Informationen 3 Updates 34, 40 UPS 115 UStG 66

V Value driven Klassifizierung 186 Vektorgrafiken 272 Verbesserung der Security 214 Verbesserung und Gewährleistung der Qualität 319 Verbesserungsaktionen 286 Verdichtung 24, 29, 52 Verdichtungs- und Nutzungsphase 39 Verdichtungsphase 22, 27, 28, 56 vereinbarten Projektgrößen 350 Vereinfachung 354 Vereinfachung der Administration der Softwareinfrastruktur 34, 40, 47 Vererbung 303 Verfahren der Portfolio Analyse 13 Verfahren und Prozesse dokumentieren 258 Verfahren zur Zugangskontrolle auf Dateien oder Dienste 204 Verfügbarkeit 18 Verhaltenswissenschaftlicher Ansatz 3 Verhinderung der Dienste eine Archivesystem 227 Verhinderung von Mehrfachkopien 42 Veritas 197, 254, 256 VERITAS 257 Verkaufsförderung 12 Verlauf des Informationswertes 54 verlustbehaftete Kompression 271 verlustfreien Komprimierungsalgorithmus 270 vernetzte, mehrstufige Speicherlandschaft 237 Vernichtung 82 verschlüsselte Übertragung 199 Verschlüsselung 196

393

Verschlüsselung der Daten 241 Verschlüsselung des Backups 241 Verschlüsselung von Daten 195 Verschlüsselung von Passwörtern 328 Verschlüsselungsfunktionen 17 Verschlüsselungskonzepte für Backup-Daten 244 Verschlüsselungsmechanismen 197 Verschlüsselungsprozesse 243 Verschlüsselungsverfahren 196 Verschuldungshaftung 313 Versionsmanagements 303 Versionsmanagement-Tool 302 Versteegen 313 Verteilte Netzwerke 246, 343 verteilten Speicher-Umgebung 202 Vertraulichkeit und Konsistenz von Daten zu sichern 204 Verwaltung der Zugriffsrechte 200 verwendeten Software 40 Video-Mail 39 vier enablers 286 Vier-Felder-Portfolio 12, 13 vierten Herausforderung an die IT 19 Viren 227 Virtual Private Network 199 Virtualisierung 172, 325 Virtualisierung für den Online-, Nearline- und NAS-Bereich 113 Virtualisierung im Online-, Nearlineund NAS-Bereich 135 Virtualisierungs-Modell 134 Virtualisierungstechnologie 340 Virtual-Tape 242 Virtual-Tape-Library 242 virtuelle Backup-Volumes 242 virtuelle Data-Container 341 virtuelle Festplatte 215 virtuelle Magnetbänder 52 Virtuelle Private Network 198 virtuelle Privatnetze 198 Virtuelle Server 254, 256, 343 virtuelle Subnetzwerke 215 virtuellen LANs 214 Visualisierung der Portfolio Analyse des Informations Managements 53 Visualisierung einer Portfolio Analyse 12 VLAN 214, 337 V-Modell 298, 317, 347 V-Modell und V-Modell-XT basiertes Projektmanagement 347

394

Index

V-Modell-Referenz 319 V-Modell-XT 319, 347 volkswirtschafstheoretischen Erklärungsansätzen 3 vollkommenen Faktormärkten 3 Vollkopien 186 Vorbeugende QS-Maßnahmen 299 vorkonfigurierter Erfassungshardware 36 Vorläuferphasen 45 Vorschaubild 269 Vorschriften für die Archivierung digitaler Dokumente 263 Vorteile von Tape- und Disk-Backup 242 VPN 198, 199 VPN-Client 199 VPN-Gateway 199 VPN-Server 199 VTL 242 VTL-Instanz 242 VTL-Lösungen 243 VTP 338

W W. Edwards Deming 281 wachsender Kostendruck 1 Wachstum der Informationsmengen 15 Wachstumsdynamik 13 Wachstums-Einbruch-Reife-Muster 10 Wachstumsphase 9, 12 Walker 313 Wallmüller 313 WAN 194, 197, 202, 248–250 Web-Format 270 Webmaster 204 Wechselmedien 38, 259 Wechsels zur Desaster-Recovery-Site 279 weniger kostenintensive Medien 35, 41 wenigsten kostenintensive Medien 45 Werbung 9, 12 Wert der Daten 57 Wert der Daten nach Moore 56 Wert der Information 24 Wettbewerbsfähigkeit 19 Wettbewerbsvorteil 30, 31 Wide Area Network 226 widersprechen 261 Wiederherstellbarkeitsforderung 23 Wiederherstellungsprozess 238, 239 Wiederherstellungszeitziel 54

Wiederverwendungswahrscheinlichkeit 49, 56 Wiederverwendungswahrscheinlichkeit erstellter Daten 40, 47 WiederverwendungswahrscheinlichkeitDatenmenge-Relation 51 Wikipedia 6 Williams 313 Windows 121, 136, 257 Windows NT 201 Windows Object Manager 201 Windows Systeme 38 Wissen als vierter Produktionsfaktor 7 Wissenschaftliche/GIS-Anwendungen 38 Wissensreservoir 5 WLAN 199, 203, 243 Wolf 313 Word-Dokument 2 World Wide Name Zoning 215 World Wide Web Consortium 268 Worldcom 19 WORM 103 Wörterbuch-Attacke 244 Würmer 231 WWN 215, 216, 339 WWN Zoning 215 WWN-Spoofing 339

X XAM 182 XAM-Klassifizierung 187 XFS 201 XML 256, 267–269, 273, 275 XSI 254

Z z/OS 38 z/Series Mainframes 38 Zeitalter des E-Business 1 zeitpunktgenaue Dokumentation 289 zeittoleranten Daten 239 zeitzonenüber-greifendes Geschäft 18 zentrale Datenspeicherung 198 zentrale Steuerungsgremium des Projektes 350 zentrale Verwaltung der Benutzer 327 zentralen Datenhaltung 202 Zentralen Datenspeicherinfrastrukturen 202

Index

zentralen Managementstation 327 zentraler Gegenstand des Strategischen Managements 3 Zentralisiertes Backup-to-Tape 248 Zero or little data loss – Server exclusive/shared 252 Zertifikate 104, 196, 321 Ziel der Senkung der TCO 46 Ziele der Strategischen IT-Planung 119 zielgerichteten Bereitstellung von Information 3 zielgerichteten Speicherung 1 Zingel 10

395

Zivilprozessordnung 60, 80 Zoning 195, 214, 216, 338 Zoning im SCSI-Protokoll 215 Zugang zu allen Speicherelementen 257 Zugangskontrolle 197, 234 Zugriff 18 zugriffsberechtigten Server 215 Zugriffskontrolle 196 Zugriffssoftware 18 Zugriffstabellen 215 Zulässige Archivierungsformen 263 Zwischensicherung 26 Zyklus-und-Erneuerung-Muster 10