Erstellung und Einführung eines Notfallkonzeptes im IT-Bereich eines Mittel- bis Großunternehmens


Diplomarbeit, 2000

76 Seiten, Note: 1


Leseprobe


Inhaltsverzeichnis

1 Einleitung
1.1 Sensibilisierung zum Thema
1.2 Erläuterungen und Begründungen der Themenwahl (Motivation)
1.3 Entstehungsgeschichte
1.4 Nutzen eines Notfallkonzeptes
1.5 Einbettung in das Forschungsumfeld
1.6 Ziele der Arbeit

2 Grundlagen
2.1 Gefährdungsarten
2.2 Sicherheitsmanagement
2.2.1 Aufgabe des Sicherheitsmanagements
2.2.2 Maßnahmen des Sicherheitsmanagements
2.2.3 Rechenzentrumssicherheit
2.3 Risikoanalyse
2.3.1 Risikobegriff
2.3.2 Risikobewertung
2.3.3 Zweck der Risikoanalyse
2.3.4 Risikoklassen
2.4 Katastrophenmanagement
2.4.1 Aufgaben des Katastrophenmanagements
2.4.2 Vorgehensweise
2.4.3 Vorsorgeplanung
2.4.4 Einsatzplanung
2.4.5 Wiederanlaufplanung
2.5 Theoretischer Ablauf der Notfallvorsorge
2.5.1 Zweckbeschreibung
2.5.2 Schritte der Notfallvorsorge
2.5.3 Schwachstellen einer Notfallvorsorgelösung
2.6 Backupkonzepte (kalt, warm, heiß)
2.6.1 Kaltes Backup
2.6.2 Warmes Backup
2.6.3 Heißes Backup

3 Analyse verschiedener Lösungsansätze
3.1 Entwicklung einer Word u. Excel Dokumentation
3.2 Entwicklung einer Datenbankapplikation
3.3 Entwicklung mit Standardsoftware ROGSI/DMS
3.4 Benchmark der Varianten

4 Realisierung eines Notfallkonzeptes mit ROGSI V.3.3.1
4.1 Allgemeine Beschreibung
4.2 Anwendungsbereiche und Möglichkeiten des Werkzeugs
4.3 Stammdaten der Notfallplanung im DMS
4.3.1 Firmen
4.3.2 Lokationen
4.3.3 Personen
4.3.4 Teams
4.3.5 Verträge
4.3.6 Systeme
4.3.7 Modelle und Hardware
4.3.8 Software
4.3.9 Planung
4.4 Beschreibung Report Generator RPT
4.5 Schwachstellenanalyse von Rogsi

5 Umsetzung auf das Rechenzentrum
5.1 Überblick zur Vorgehensweise
5.2 Phasenplan der Umsetzung
5.3 Definition des Projekts
5.4 Risikoanalyse
5.4.1 Abhängigkeiten der Systeme
5.4.2 Priorisierung der Server
5.4.3 LAN- Analyse
5.5 Stammdatenaufbau in der Notfalldatenbank
5.5.1 Schema der Verteilung der Notfalldokumente
5.5.2 Firmenverzeichnis
5.5.3 Lokationsverzeichnis
5.5.4 Personenverzeichnis
5.5.5 Teamverzeichnis
5.5.6 Verträge
5.5.7 Systeme
5.5.8 Modellverzeichnis
5.5.9 Hardwareverzeichnis
5.5.10 Softwareverwaltung
5.5.11 Dokumente/ Beschreibungen
5.6 Wiederanlaufpläne erstellen
5.6.1 Grundsatzüberlegung
5.6.2 Nummernvergabeschlüssel der Planung
5.7 Einzelne Pläne im Detail
5.7.1 Stromausfall
5.7.2 Zerstörung Rechenzentrum
5.7.3 Zerstörung Ausweichrechenzentrum
5.7.4 Ausfall LAN
5.7.5 Ausfall WAN
5.8 Reports für NFHB erstellen
5.8.1 Firmenreport
5.8.2 Personenreport
5.8.3 Teamreport
5.8.4 Hardwarereport
5.8.5 Softwarereport
5.8.6 Vertragsreport
5.8.7 Lokationsreport
5.8.8 Planreport
5.9 Notfallhandbuch erstellen
5.10 Schulung - Einführungssphase

6 Wirtschaftliche Betrachtung
6.1 Risiko
6.2 Nutzen
6.3 Kosten, Schaden
6.4 Progressiver Anstieg des Schadens
6.5 Finanzierungskostenverlauf
6.6 Investitionsrechnung

7 Rechtliche Aspekte
7.1 Rechtssituation in Deutschland
7.2 Rechtslage in Österreich

8 Schlussfolgerung

9 Ausblick auf zukünftige Arbeiten

10 Zusammenfassung

Literaturverzeichnis

Abkürzungsverzeichnis

Anhang

Datenmodell von Rogsi V3.3.1

Projektplan

Interviewbogen

Danksagung

Mein Dank gilt in erster Linie meinen Eltern und meiner Großmutter, sie haben mir das Studium durch ihre Unterstützung erst möglich gemacht.

Seitens der Firma bedanke ich mich bei allen am Projekt beteiligten Mitarbeiter für die äußerst konstruktive und angenehme Zusammenarbeit, ohne diese Bereitschaft wäre ein Ergebnis in dieser Form mit Sicherheit nicht möglich gewesen.

Mein besonderer Dank gilt Herrn Weiss und Herrn Plainer, sie haben durch ihre jederzeitige Diskussionsbereitschaft und Unterstützung durch Feedback und konstruktive Anmerkungen einen enorm wertvollen Beitrag zum Gelingen dieser Arbeit geleistet.

Nicht zuletzt bedanke ich mich bei meinem Betreuer von der Fachhochschule Salzburg, Herrn DI Karl Kreuzhuber für die außerordentlich gute Betreuung und engagierte Unterstützung - sogar vom Krankenhausbett aus.

Kurzfassung / Abstract

Zu- und Vorname: Anton Gruber Studiengang: TKS

Kurztitel der Diplomarbeit: Erstellung und Einführung eines Notfallkonzeptes im ITBereich eines Mittel- bis Großunternehmens

Betreuer an der FH: Dipl.Ing. Karl Kreuzhuber Betreuer in der Firma: Weiss Christian, Bosch

Schlagw ö rter zur Diplomarbeit:

1.Schlagwort: Notfallkonzept, IT- Bereich, Notfalldatenbank
2.Schlagwort: Wiederanlaufplanung, Katastrophenfall
3.Schlagwort: Notfallplanung, Rechenzentrumssicherheit

After a comprehensive introduction to the subject, in the first main part of this diploma dissertation theoretical background information is discussed. The second part deals with the fundamental realization of a IT- emergency concept with the help of Rogsi/DMS a software tool to construct a disaster management system. The third and major part discusses the practical implementation of such a system at the computer center and network environment of a middle sized company. Especially the procedure and the way the things were handled are concerned. The key part of the paper also deals with the construction and usage of an emergency database. The emergency data is serviced online and an emergency handbook can be automatically generated. But that is not the end of the story, the next point refer to economic and legal issues. The final part is a summary that contains an outlook to possible further developments in near future.

This pamphlet contains a problem description, necessary working steps and some reached results of the project. The importance of the subject disaster management is underestimated, especially in small and middle sized companies. Frequently there is no emergency concept realised to handle a complete data and hardware breakdown. Statistics confirm the speculation, that a IT- dead loss causes enormous financial loss. If a recovery trial does not happen in good time a bankruptcy is mostly unavoidable. A goal-directed emergency concept with the use of modern technology (emergency database) can reduce this difficulty.

Abbildungsverzeichnis

Abbildung 1.1 Schematische Arbeitsaufwandverteilung

Abbildung 1.2 Einsparungspotential durch Verhütungsmaßnahmen (Quelle:8)

Abbildung 2.1 Schadensursachen und Gefährdungsarten (angelehnt an Quelle:3)

Abbildung 2.2 Ursachen von Katastrophenfällen im IT- Sektor

Abbildung 2.3 Abdeckung des Risikopotentials

Abbildung 2.4 Die drei Stützsäulen eines Sicherheitskonzepts (Quelle:3)

Abbildung 2.5 Spektrum von Wissenszuständen (Quelle:4)

Abbildung 2.6 Risikoklassen- Portfolio (Quelle:1, nach Krallmann)

Abbildung 2.7 Zeitlicher Verlauf eines K- Falls

Abbildung 2.8 Positionierung der Notfallvorsorgedokumentation

Abbildung 2.9 Schwachstellen im IT- Notfallkonzept (angelehnt an Quelle:1)

Abbildung 2.10 Schema eines kalten Ausweichrechenzentrums

Abbildung 2.11 Schema eines heißen Ausweichrechenzentrums

Abbildung 3.1 Vergleich der Lösungsvarianten anhand des Arbeitsaufwands

Abbildung 4.1 mögliche Rogsi- Installationsvarianten

Abbildung 4.2 Firmenentität mit Verknüpfungen

Abbildung 4.3 Beispiel der Eingabemaske- Firmen

Abbildung 4.4 Lokationsentität mit Verknüpfungen

Abbildung 4.5 Personenentität mit Verknüpfungen

Abbildung 4.6 Team mit Verknüpfungen

Abbildung 4.7 Vertrag mit Verknüpfungen

Abbildung 4.8 System mit Verknüpfungen

Abbildung 4.9 Modelle und Hardware mit Verknüpfungen

Abbildung 4.10 Software mit Verknüpfungen

Abbildung 4.11 Planelemente mit Verknüpfungen

Abbildung 4.12 Ansichtsfenster graphische Pläne

Abbildung 4.13 Zusammenstellen der Reports

Abbildung 5.1 Schema der Vorgehensweise

Abbildung 5.2 Projektphasenplan der praktischen Realisierung

Abbildung 5.3 Auszug aus dem Projektplan

Abbildung 5.4 Graphische Darstellung der Abhängigkeiten von IT- Systemen

Abbildung 5.5 Aufstellung der Server mit Priorisierung für den Notfall

Abbildung 5.6 Vernetzungsschema der Netzwerkverteilerknoten

Abbildung 5.7 Detailansicht eines Netzwerkknotens

Abbildung 5.8 Ausfallwahrscheinlichkeiten der einzelnen Netzknoten

Abbildung 5.9 Schema der Notfalldatenverteilung in einem Unterverzeichnisbaum

Abbildung 5.10 Screenshot- Firmenverzeichnis

Abbildung 5.11 Screenshot- Lokationsverzeichnis

Abbildung 5.12 Screenshot- Personenverzeichnis

Abbildung 5.13 Screenshot- Teamverzeichnis

Abbildung 5.14 Screenshot- Vertragsverzeichnis

Abbildung 5.15 Einbindung der Verträge in elektronischer Form

Abbildung 5.16 Screenshot- Systemverzeichnis

Abbildung 5.17 Screenshot- Modellverzeichnis

Abbildung 5.18 Screenshot- Hardwareverzeichnis

Abbildung 5.19 Screenshot- Softwareverzeichnis

Abbildung 5.20 Screenshot- Dokumentenverzeichnis

Abbildung 5.21 Klassifizierung von Katastrophen und Notfällen

Abbildung 5.22 Ansicht Tabelle- Planungselemente

Abbildung 5.23 Auszug aus dem Notfallplan für einen Stromausfall

Abbildung 5.24 Auszug aus dem Notfallplan bei einer Zerstörung des Rechenzentrums .

Abbildung 5.25 Auszug aus dem Notfallplan für den Ausfall des LAN

Abbildung 5.26 Auszug aus dem Notfallplan bei Ausfall der WAN- Verbindung

Abbildung 5.27 Datenfelder des Firmenreports

Abbildung 5.28 Datenfelder des Personenreports

Abbildung 5.29 Datenfelder des Teamreports

Abbildung 5.30 Beispiel eines generierten Team- Datensatzes

Abbildung 5.31 Datenfelder des Teamreports

Abbildung 5.32 Beispiel eines generierten Hardware- Datensatzes

Abbildung 5.33 Datenfelder des Softwarereports

Abbildung 5.34 Datenfelder des Vertragreports

Abbildung 5.35 Datenfelder des Vertragreports

Abbildung 5.36 Datenfelder des Planreports

Abbildung 5.37 Beispiel eines generierten Hardware- Datensatzes

Abbildung 5.38 Auszug aus dem generierten Notfallhandbuch

Abbildung 5.39 Strukturbaum des Notfallhandbuchs

Abbildung 5.40 Inhalte der Präsentation zur Projektvorstellung

Abbildung 6.1 Progressiver Kostenverlauf

Abbildung 6.2 Finanzierungskosten eines Risikos (Quelle:3)

Abbildung 6.3 Break- Even Diagramm

1 Einleitung

Die Abhängigkeit von den Informationstechnologiediensten läßt sich vom Anwender oft erst dann erkennen, wenn die technische Einrichtung oder der Dienst nicht mehr funktioniert und nicht mehr zur Verfügung steht. Sogar kurzfristige Unterbrechungen können in bestimmten Branchen gigantische Schäden anrichten und damit verbundene finanzielle Verluste herbeiführen. Die vorliegende Arbeit setzt sich umfassend mit der angesprochenen Thematik auseinander. Nach einer einleitenden Hinführung zum Thema und Darlegung der Problematik werden die theoretischen Grundlagen zum jetzigen Stand der Literatur vermittelt. Darauf folgt eine Analyse verschiedener Lösungsansätze. Genauer eingegangen wird auf die Realisierung mit einem Softwaretool, welches genau für diesen Zweck konzipiert wurde. Zum Hauptteil dieser Arbeit zählt natürlich die praktische Umsetzung auf ein Rechenzentrum. Die Vorgehensweise und die gemachten Erfahrungen wurden soweit aus datenschutzrechtlichen Gründen möglich, in dieser praktischen Arbeit dokumentiert. Um eine „Scheuklappensichtweise“ eines Technikers zu vermeiden, sind natürlich auch betriebswirtschaftliche und rechtliche Aspekte in die Arbeit eingeflossen. Die Arbeit ist abgerundet mit einem Ausblick auf weitere mögliche Ergänzungsarbeiten und einer Zusammenfassung.

1.1 Sensibilisierung zum Thema

Durch die Entwicklung ganzheitlicher Informationssysteme nimmt die Abhängigkeit der Unternehmen von einem funktionierenden Informationssystem zu. Bereits Teilausfälle des Informationssystems können sich unternehmensweit auswirken.1

Die Wahrscheinlichkeit, einen K- Fall (Katastrophenfall) zu erleiden ist größer als angenommen, laut IBM liegt das Risiko bei 2 Promille. Die Ursachen können sehr vielfältig sein und nach einem K- Fall drohen hoher finanzieller Schaden bis hin zum Konkurs, Arbeitsplatzverluste, Imageschäden und Folgeschäden. Geschäftsführer und verantwortliche Mitarbeiter werden persönlich haftbar gemacht. Eine nicht etablierte K- Vorsorgelösung wird dem RZ- Leiter und dem zuständigen Geschäftsführer im K- Fall als grobe Fahrlässigkeit ausgelegt. Die Tatsache, dass ein Risiko über Generationen nicht zu einem Schaden geführt hat, ist keinesfalls ein Entlastungsmoment, sondern im Gegenteil, es birgt die Gefahr, dass das Risikopotential unterschätzt wird und keine Maßnahmen eingeleitet werden. Laut statistischer Erfahrung verdichtet sich die Schadenseintrittswahrscheinlichkeit mit einer zunehmenden Ruhepause. [2,5]

1.2 Erläuterungen und Begründungen der Themenwahl (Motivation)

Elektronisch gespeicherte Daten ersetzten zunehmend die herkömmlichen Formen der Darstellung und Archivierung. Ihnen kommt zunehmend die Bedeutung einer Sache zu, mit allen formalen und rechtlichen Konsequenzen. Durch die Durchdringung der Unternehmen mit Informationstechnologie und deren umfassender Einsatz in nahezu allen Unternehmensbereichen (Schlagwörter: CAD, CAM, CAQ, CIM, PPS, etc.) ist die Funktionsfähigkeit vieler Unternehmen, die keine etablierte IT- Notfallvorsorgelösung haben gefährdet. Diese Situation deutet darauf hin, dass auch in Zukunft die Nachfrage an solchen Lösungen steigen wird. Die Motivation genau dieses Thema zu behandeln ist natürlich auch damit begründet, dass sich der Markt für softwareunterstützte Notfallvorsorgelösungen in Form einer Notfalldatenbank öffnen wird und somit ein Themenkreis behandelt wird, der in Zukunft eine wichtige Rolle spielen wird. Auch der Trend im Qualitätsmanagement geht weiter in Richtung vorbeugende Planung, da liefert diese in die Praxis umgesetzte Arbeit neue Denkanstöße und nützliche Lösungsansätze.

1.3 Entstehungsgeschichte

Die eigentliche Einarbeitungsphase auf dem Gebiet der Notfallplanung, geschah im Rahmen des Berufspraktikums. Die erste Aufgabenstellung war es einen JHW (Jahrhundertwechsel) - Notfallplan zu erarbeiten. Darauf aufbauend entstand die Idee die gewonnenen Erkenntnisse in die generelle Notfallvorsorgelösung einfließen zu lassen und in einer Notfalldatenbank zu dokumentieren. Die allgemeine Vorgehensweise und die Verteilung des Arbeitsaufwands ist in der folgenden Abbildung verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1 Schematische Arbeitsaufwandverteilung

Hinweis: Aus Datenschutzgründen sind natürlich keine geheimen Informationen aus dem eigentlichen Notfallhandbuch und Notfallkonzept in die Diplomarbeit eingeflossen.

1.4 Nutzen eines Notfallkonzeptes

Durch die Installation eines Notfallkonzeptes werden die Gefahren aus der gesteigerten Abhängigkeit von der IT- Infrastruktur deutlich abgeschwächt. Enorme finanzielle Verluste und Imageeinbußen durch längere Betriebsunterbrechungen werden durch die Notfallvorsorge abgefangen. Gerade in Zeiten wie diesen kann eine abgesicherte Produktions- und Liefersicherheit zum entscheidenden Marketinginstrument werden. Das Onlinesystem erlaubt den Zugriff auf eine Vielzahl von Informationen, die in einer verteilten Dokumentation in der Form und Qualität nicht verfügbar ist. Jeder Anwender hat im Notfall Zugriff auf wichtige Informationen, wobei die Pflege der Daten verteilt durch die jeweiligen Fachspezialisten erfolgen kann. Die Dokumentation mit einem einheitlichen System reduziert die Unterbrechungszeiten und verhindert Fehler bei der Behebung der Störungen. Durch den Einsatz von Links auf andere Dokumente bestehen fast keine Grenzen in der Anwendung in der Rechenzentrumsdokumentation. Dazu kommt, dass der aktuelle Datenbestand jederzeit in Form von Handbücher und Berichten in Papierform ausgedruckt werden kann. Zusätzlich kann der Notfalldatenbestand auf ein Notebook übertragen werden, um eine örtliche Trennung zu ermöglichen.

1.5 Einbettung in das Forschungsumfeld

Angesicht der Tatsache, dass relativ wenig deutschsprachige Literatur zur Verfügung steht und die Bedeutung solcher Lösungen im Steigen begriffen ist lässt sich erkennen, dass es sich großteils noch um unbeackertes Gebiet handelt.

Eines ist klar: organisatorische, sicherheitsbezogene Maßnahmen sind kaum in ihrer Wirkung objektiv zu erfassen. Denn ein durch vorbeugende Maßnahmen verhinderter Notfall/Ausfall lässt sich rechnerisch nicht nachweisen. Doch Erfahrungen im Qualitätsmanagement bestätigen die hohe Relevanz von vorbeugenden Maßnahmen. Eine Investition in Fehlerverhütungskosten führt dazu, dass das Auftreten von Fehlern reduziert wird und somit die Fehlerkosten sinken. Im Endeffekt ergibt sich daraus eine Kosteneinsparung, die einem zusätzlichen Gewinn gleichzusetzen ist. Das wird in der folgenden Grafik aufgezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2 Einsparungspotential durch Verhütungsmaßnahmen (Quelle:8 )

1.6 Ziele der Arbeit

Bei der Projektdefinition wurden mehrere allgemeine Ziele gesteckt, die während des gesamten Projektverlaufs als Richtpfeiler dienten, damit die Richtung und Zielsetzung zu jedem Zeitpunkt des Projekts unverrückbar feststand.

Eines der Hauptziele ist es die Reaktionszeit bei Stör-, Not-, u. Katastrophenfällen zu reduzieren. Die im Vorfeld definierten Maßnahmen sollen dazu beitragen, dass keine oder kürzere Ausfallszeiten entstehen und der Schaden so gering wie nur möglich gehalten wird. Im Verlauf des Projektes (insbesondere in der Phase der Risikoanalyse) sollen Schwachstellen und Restrisiken erkannt, aufgezeigt und Maßnahmen zur Entschärfung eingeleitet werden. Denn mit Analysen allein bewegt man im Unternehmen rein gar nichts.

Ein weiteres nicht zu unterschätzendes Ziel muss es sein, die Rechenzentrumsdokumentation an einem zentralen Punkt zusammenfließen zu lassen, und das am besten mit Hilfe einer Notfalldatenbank. Dabei ist es absolut wichtig, die Ausarbeitung so praxisnah und anwendungsgerecht zu gestallten, dass die notwendige Akzeptanz der Mitarbeiter vorhanden ist. Dies ist nur dann erreichbar, wenn ein möglichst geringer Wartungsaufwand bei gleichzeitig hohem Nutzen angestrebt wird.

2 Grundlagen

2.1 Gefährdungsarten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1 Schadensursachen und Gefährdungsarten (angelehnt an Quelle:3 )

Die Ausfallursachen und Gefährdungsarten können am umfassendsten den Statistiken der Schaden-, Sach- und Elektronikversicherer entnommen werden.

Das folgende Diagramm zeigt eine Verteilung von Katastrophenfällen auf, die sich im ITUmfeld ergeben haben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2 Ursachen von Katastrophenfällen im IT- Sektor

2.2 Sicherheitsmanagement

2.2.1 Aufgabe des Sicherheitsmanagements

Die zentrale Aufgabe des Sicherheitsmanagements ist die Erreichung der gesteckten

Sicherheitsziele, genauer gesagt das Abwenden von realen Schäden an der Informationsinfrastruktur und daraus erwachsenden wirtschaftlichen Schäden durch Festlegen von Sicherungsmaßnahmen, Abdecken mit Versicherungen sowie auch das Tragen eines gewissen Restrisikos. Die Höhe des Restrisikos sollte jedoch bekannt sein. Der Umfang hängt von der Risikobereitschaft der Unternehmung ab.1 Die Aufgabenerfüllung erfolgt durch das rechtzeitige Erkennen von Bedrohungen, das Abschätzen vom möglichen Schadensausmaß sowie durch das Planen und Realisieren von Maßnahmen. Das Risikopotential und das Schutzpotential sollen so aufeinander abgestimmt sein, das weder ein unkalkulierbares Restrisiko verbleibt, noch sinnlose und unwirtschaftliche Sicherungsmaßnahmen implementiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3 Abdeckung des Risikopotentials

Die Bedrohungen und auch die Informationsinfrastruktur ändern sich ständig, daher sollen die Bedrohungs- u. Schwachstellenanalyse regelmäßig (aus heutiger Sicht mindestens einmal pro Jahr) wiederholt werden. Zusammen bilden sie die sogenannte Risikoanalyse, die im Kapitel 2.3 ausführlich beschrieben wird.

2.2.2 Maßnahmen des Sicherheitsmanagements

Es ist von großer Bedeutung, dass die Sicherungsmaßnahmen so konzipiert und aufeinander abgestimmt sind, sodass die Sicherheits- und Schutzziele so wirksam und wirtschaftlich wie möglich erreicht werden. Nur dann wenn organisatorische, technische und bauliche Maßnahmen gleichermaßen bei der Konzepterstellung Berücksichtigung finden, kann die angestrebte Lückenlosigkeit annäherungsweise erreicht werden.3

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4 Die drei Stützsäulen eines Sicherheitskonzepts (Quelle:3 )

Man kann die Maßnahmen auch nach ihrer Wirksamkeit gruppieren. Dann entsteht ein abgestuftes System von Maßnahmenkategorien. Im Falle des Versagens einer Kategorie, werden die der nächsten Kategorie wirksam. So entsteht ein System von aufeinander aufbauenden und sich ergänzenden Maßnahmenkategorien:1

- Vermeidung eines realen Schadens. Die Sicherungsmaßnahmen versuchen das Eintreten des Schadens zu verhindern. Das heißt die Eintrittswahrscheinlichkeit wird minimiert. (z.B. durch Gebäudeschutz, Blitzableiter, redundantes Powersupply)
- Verminderung des realen Schadens. Ein eingetretener Schaden soll rechtzeitig entdeckt werden, um seine Ausbreitung bzw. Vergrößerung zu verhindern. (z.B. Brandmelder, Feuchtigkeitsmelder, etc.)
- Begrenzung des Risikos. Ein realer Schaden kann zu einem wirtschaftlichen Schaden führen. Der Schaden kann zum Beispiel durch Wartungsverträge vermieden werden.
- Begrenzung des wirtschaftlichen Schadens. Diese Kosten sollen so klein wie möglich gehalten werden, beispielsweise durch Aufrechterhaltung eines Notbetriebs in einem Ausweichrechenzentrum.
- Finanzielle Vorsorge f ü r den Schadensfall. (z.B. durch Versicherungen oder Rücklagen)

2.2.3 Rechenzentrumssicherheit

Die Sicherheit der Informationsstruktur ist wesentlich von der Sicherheit der Hostsysteme abhängig. Für das Sicherheitsmanagement bedeutet das, dass das Rechenzentrum und dessen Betrieb ein erhebliches Risiko bergen. Zur Aufrechterhaltung der RZ- Sicherheit muss den Mitarbeitern ein ausgeprägtes Sicherheitsbewusstsein vermittelt werden. Die Einhaltung der Sicherungsmaßnahmen muss laufend überwacht werden und Nichteinhaltungen müssen verfolgt werden. Dazu kommt die ständige Beobachtung der bekannten Risiken und die regelmäßige Abhaltung von Sicherheitsanalysen, um neue Risiken zu erkennen.

Ein Forschungsbefund vom TÜV kommt zum Ergebnis, dass die größte Sicherheitslücke die Mitarbeiter sind. Ein Grund dafür könnte auch die mangelhafte Sensibilität für Sicherheit der Vorgesetzten von EDV- Leitern sein. Daraus folgt, dass das Risikopotential durch personelle Maßnahmen (Schulung, etc.) dauerhaft gesenkt werden kann. 1

2.3 Risikoanalyse

2.3.1 Risikobegriff

Definition:

„ Risiko ist die negative Abweichung von einem erwarteten Zustand bezogen auf ein Objekt in einem Zielsystem durch ein Ereignis mit verschieden wahrscheinlichen Auspr ä gungen. “

[4, Seite 42]

Eine verbreitete Klassifikation von Risken ist die Einteilung in „reine“ und „spekulative“ Risiken. Reine Risiken schließen nur negative, für die Unternehmung nachteilige Folgen ein (dazu zählen z.B. Brand, Lebensdauer einer HW- Komponente, etc.). Im Gegensatz dazu beinhalten spekulative Risiken auch gleichzeitig eine „Gewinnchance“. Das kann der Fall sein, wenn in eine Sicherheitsmaßnahme nicht investiert wird, und glücklicher Weise nichts passiert. In diesem Fall hätte man auf den ersten Blick Geld gespart.

2.3.2 Risikobewertung

Die Bestimmung der Eintrittswahrscheinlichkeit kann aufgrund vorliegendem statistischen Zahlenmaterials oder subjektiver Schätzung erfolgen. Dieser Unterschied bei der Ermittlung ist ein Kriterium beim Klassifizieren zwischen Unsicherheit und Risiko. Die folgende Abbildung zeigt das sogenannte Wissensspektrum, welches sich daraus ergibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5 Spektrum von Wissenszuständen (Quelle:4 )

2.3.3 Zweck der Risikoanalyse

Die Risikoanalyse dient dazu den Istwert der IT- Sicherheit zu bestimmen, dieser Wert

kann dem Sollwert aus den Sicherheitszielen gegenübergestellt werden (Soll/Ist- Vergleich). Diese Analysemethode setzt voraus, dass die Eintrittswahrscheinlichkeit aller unerwünschten Ereignisse, die die Sicherheit gefährden, und die Schadenshöhe je Ereigniseintritt entweder bekannt sind oder entsprechend zuverlässig angenähert werden können.

2.3.4 Risikoklassen

Zur Abgrenzung der Aufgaben des Notfallmanagements von den Aufgaben des Katastrophenmanagements kann das sogenannte Risikoklassenportfolio verwendet werden. Auf der x- Achse ist die Eintrittswahrscheinlichkeit eines Ereignisses, und auf der y- Achse die Schadenshöhe aufgetragen. Die vier Felder sind die Risikoklassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6 Risikoklassen- Portfolio (Quelle:1, nach Krallmann)

Risikoklasse A:

In diesem Fall gibt es so gut wie keine sinnvollen Maßnahmen des Sicherheitsmanagements, daher sind diese unrealistischen Fälle nicht Gegenstand des SM.

Risikoklasse B:

Bei niedriger Eintrittswahrscheinlichkeit und bei gleichzeitig hohem Schaden liegen die Problemfälle. Mit solchen Problemfällen befasst sich das Katastrophenmanagement.

Risikoklasse C:

Bei hoher Eintrittswahrscheinlichkeit und geringer Schadenshöhe handelt es sich um Routinefälle (Störungen). Die Durchschaubarkeit der Ereignisse ist relativ groß.

Risikoklasse D:

Diese Fälle sind unwahrscheinlich und nicht wichtig, daher als unkritisch zu werten. Sie bedürfen keiner besonderen Beachtung, da sie ohnehin abgedeckt sind.1

2.4 Katastrophenmanagement

2.4.1 Aufgaben des Katastrophenmanagements

Das Katastrophenmanagement zielt auf solche Schäden ab, deren

Eintrittswahrscheinlichkeit niedrig und deren Folgen als Schadenshöhe als groß eingeschätzt werden. Eine Katastrophe hat zu Folge, dass die Informationsinfrastruktur ganz oder in den wichtigsten Teilen beschädigt oder zerstört ist. Eine Folge eines K- Falls ist , dass die Beeinträchtigung nicht unmittelbar beseitigt werden kann. Daher ist es eine Kernaufgabe einen Überlebenszeitraum Tü des Unternehmens ohne IT herzustellen, der nicht kleiner, höchstens gleich der Wiederanlaufzeit Ta ist. Die Aufgabe kann durch Verlängerung von Tü oder der Verkürzung von Ta bewältigt werden. Eine Verlängerung von Tü kann durch eine gute Notfallorganisation erreicht werden. Hingegen bewirken Maßnahmen der Katastrophenplanung (Wiederanlaufpläne, Verträge mit Anbietern von mobilen Ausweichrechenzentren, etc.) eine Verkürzung von Ta. Ziel muss es sein die Reservezeit oder Bufferzeit Tr zu maximieren. Die folgende Abbildung verdeutlicht den beschriebenen Sachverhalt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7 Zeitlicher Verlauf eines K- Falls

Ein Katastrophenplan kann ein mangelhaftes Sicherungssystem keinesfalls ersetzen, vielmehr ist er ein Leitfaden im K- Fall.

Nach einem Forschungsbefund, der von IBM in den USA in Auftrag gegeben wurde, wird der Überlebenszeitraum Tü für Bankbetriebe mit 2 Tagen, für Handelbetriebe mit 3,3 für Industriebetriebe mit 4,9 und für Versicherungsbetriebe mit 5,6 Tagen angegeben.1

2.4.2 Vorgehensweise

Ausgehend von den Ergebnissen der Risikoanalyse werden in der Katastrophenplanung Vorsorgemaßnahmen gegen den Eintritt eines K- Falls und Eventualmaßnahmen für den Eintritt festgelegt. Es erweist sich als sinnvoll, den Totalausfall der IT- Infrastruktur zur

Grundlage der Planung zu machen. Davon können die Varianten der eingeschränkten Funktionsfähigkeit auf einfache Art und Weise abgeleitet werden und dokumentiert werden. Ein Katastrophenplan soll übersichtlich in Teilpläne gegliedert sein. Diese können sein: Vorbemerkung, Vorsorgeplan, Einsatzplan und Wiederanlaufplan. Die Vorbemerkung enthält Informationen wie Gültigkeitsbereich, Aufbewahrungsorte, Mitglieder des Krisenstabs und Zuständigkeiten für die Erstellung und Pflege des Plans, die zwingend erforderlich sind um die Aktualität gewährleisten zu können.

2.4.3 Vorsorgeplanung

Ziel der Vorsorgeplanung ist es den Eintritt eines K- Falls zu vermeiden. Sie beinhaltet vorbeugende Maßnahmen baulicher, technischer, personeller und organisatorischer Art. Der Vorsorgeplan sollte enthalten: interne und externe Anschriften, Weisungsbefugnisse, vorgesehene Lautsprecherdurchsagen, Verträge mit HW/SW- Lieferanten, Aufbewahrungsorte, etc. Eine detaillierte Auflistung ist in1 zu finden.

2.4.4 Einsatzplanung

Der Einsatzplan beschreibt die vorgesehenen Sofortmaßnahmen zum Zeitpunkt des Eintritts eines K- Falls. Er beschreibt die Alarmauslösung, Meldung des K- Falls, Bekämpfen der Schadensursache, Retten des Archivs und der Hardware und die Bestandsaufnahme des Schadens.

2.4.5 Wiederanlaufplanung

Der Wiederanlaufplan ist der umfangreichste Teil des Katastrophenplans. Er beinhaltet alle Maßnahmen, die zum Wiederanlauf des Rechenzentrums notwendig sind, angefangen bei der Ersatzbeschaffung von Räumen und Betriebsmitteln und die Installation der Ersatzkonfiguration bis hin zur Umstellung vom Notbetrieb auf den Normalbetrieb. Die Wiederanlaufpläne hängen sehr stark vom gewählten ARZ- Backupsystem (Kapitel 2.6) ab.

2.5 Theoretischer Ablauf der Notfallvorsorge

2.5.1 Zweckbeschreibung

Ziel einer umfassenden Notfallvorsorge muss es sein den Istzustand des Produktivsystems in der Notfallvorsorgedokumentation in einem Abbild der Realität abzulegen. Dann ist es möglich bei einer Zerstörung des Systems anhand dieses Abbildes den Urzustand wiederherzustellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8 Positionierung der Notfallvorsorgedokumentation

2.5.2 Schritte der Notfallvorsorge

Laut dem Deutschen Bundesamt für Sicherheit in der Informationstechnik (Quelle:6 ) gibt es 12 wesentliche Schritte:

Erstellung einer Ü bersicht der Verf ü gbarkeitsanforderungen: Die Verfügbarkeits- anforderungen aller einzelner IT- Systeme, sprich die tolerierbare Ausfallzeit liefert wichtige Entscheidungsinformation. Diese Übersicht entsteht in Zusammenarbeit mit den Verfahrensverantwortlichen und erleichtert es, die besonders zeitkritischen Komponenten zu extrahieren.

Notfall- Definition, Notfall- Verantwortlicher: Die autorisierte und rechtzeitige Einleitung von Notfallmaßnahmen bedarf der Benennung eines Notfall- Verantwortlichen.

Erstellung eines Notfallhandbuches: Im Notfallhandbuch sind alle Maßnahmen, die zu ergreifen sind mit den dazu nötigen Informationen zu dokumentieren. Der Detaillierungsgrad sollte so ausgelegt sein, dass ein sachverständiger Dritter in der Lage ist, die spezifizierten Maßnahmen einzuleiten und durchzuführen. Die Struktur eines NFHBs ist im praktischen Teil (Kapitel 5) näher beschrieben.

Dokumentation der Kapazit ä tsanforderungen der IT- Anwendungen: Diese Maßnahme ist wichtig im Hinblick auf interne und externe Ausweichmöglichkeiten für den Betrieb der IT- Anwendungen. Kapazitätswerte die man dokumentieren sollte sind: CPU- Leistung, Plattenkapazitäten, Partitionierungsplan, Bandbreite, etc. Es soll geprüft werden, ob die Kapazitäten im Notfall reduziert werden können, damit ein Notbetrieb möglich ist.

Definition des eingeschr ä nkten IT- Betriebs: Für den Fall, dass einige Teile des ITSystems ausfallen, ist zu eruieren, ob ein eingeschränkter IT- Notbetrieb möglich ist.

Untersuchung interner und externer Ausweichm ö glichkeiten: Bei der Untersuchung von Ausweichmöglichkeiten ist insbesondere auf die technischen Anforderungen an das ErsatzIT- System zu achten. Zuallererst steht die interne Verlagerung von IT- Anwendungen von einem IT- System auf ein anderes IT- System im Vordergrund (z. B. Ausweichen auf den Entwicklungsrechner, wenn der Produktionsrechner ausfällt).

Regelung der Verantwortung im Notfall: Für den Zeitraum nach Eintritt des schädigenden Ereignisses bis hin zur kompletten Wiederherstellung der Verfügbarkeit ist eine zeitlich befristete Notfall-Organisation erforderlich. Es müssen Verantwortliche bestimmt werden, die befugt sind zu entscheiden, ob es sich um einen Notfall handelt, und die die entsprechenden Maßnahmen des Notfallplans einleiten

Alarmierungsplan: Ein Alarmierungsplan beschreibt den Meldewegs, über den bei Eintritt eines Notfalls die zuständigen Personen oder Organisationseinheiten zu informieren sind. Der Alarmierungsplan muss allen Notfall-Verantwortlichen zur Verfügung stehen, und darüber hinaus an einer zentraler Stelle (Pforte) vorgehalten werden.

Notfallpl ä ne f ü r ausgew ä hlte Schadensereignisse: Notfall-Pläne beinhalten die Handlungsanweisungen und Verhaltensregeln für bestimmte Schadensereignisse. Dabei handelt es sich um Ereignisse, die diejenigen Teile der IT- Infrastruktur gefährden, die von existenzbedrohender Bedeutung sind. Ein Notfall-Plan muss auf die möglichst schnelle Wiederherstellung der Verfügbarkeit gerichtet sein. Die Notfall-Pläne sind je nach Umfeld für folgende Ereignisse aufzustellen: Brand, Wassereinbruch, Stromausfall, Ausfall der Klimaanlage und Ausfall der Datenfernübertragungseinrichtung.

Datensicherungsplans erstellen: Mit der Hilfe eines Datensicherungsplans kann ein sachverständiger Dritter, sämtliche für den Wiederanlauf einer IT- Anwendung erforderliche Betriebssystem- und Anwendungssoftware und deren Daten in angemessener Zeit rückspielen. Ein Datensicherungsplan gibt Auskunft über: Ort der Daten im Normalbetrieb (Plattenspeicher-Belegungsplan), den Bestand der gesicherten Daten, die Zeitplan der Datensicherungen, Art der Datensicherung (Inkrementell- oder Vollsicherung), das Verfahren zur Datensicherung und den Ort der Aufbewahrung.

Erstellen eines Verzeichnisses f ü r Wartungsvertr ä ge und Versicherungen: A uch bei einer hinreichenden Notfallplanung lassen sich gewisse Restrisiken nicht ausschließen, diese können aber durch Wartungsverträge und Versicherungen abdeckt werden.

Durchf ü hren von Notfall ü bungen: Notfallübungen sind zwecks Prüfung der Wirksamkeit von Maßnahmen der Notfallvorsorge durchzuführen. Einerseits wird im Zuge dessen der effektive und reibungslose Ablauf eines Notfallplans erprobt und andererseits werden bisher noch unerkannte Schwächen erkannt. Beispiele für solche Tests sind: Wiederanlauf nach Ausfall einer ausgewählten IT- Komponente, Wiedereinspielen von Datensicherungen, etc. Wichtig dabei ist, dass die Notfallübungen in regelmäßigen Abständen wiederholt werden. 6

2.5.3 Schwachstellen einer Notfallvorsorgelösung

Durch die unterschiedlichen, oftmals sogar konträren Ziele von Wirtschaftswissenschaftlern und Sicherheitstechnikern entstehen oftmals während der Realisierung eines Sicherheitskonzepts Differenzen.3

Daraus können Sicherheitsrisiken und Sicherheitslücken erwachsen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9 Schwachstellen im IT- Notfallkonzept (angelehnt an Quelle:1 )

2.6 Backupkonzepte (kalt, warm, heiß)

Ein entscheidender Faktor, der die Wiederanlaufzeit immens beeinflusst ist die Art des vorgesehenen externen Backupkonzepts. Von einem internen Backup spricht man bei großen zentralen Systemen, bei denen ein gewisser Teil ausfallen kann, ohne die Datenverarbeitung zu unterbrechen. Diese Systeme bieten sozusagen eine Redundanz vor Ort, und haben das Ziel die Systemverfügbarkeit zu erhöhen. Diese Maßnahmen helfen aber bei einem K- Fall (Brand, ...) wenig. Nur ein externes Backup an einer anderen Lokation kann hier eine Verminderung des Risikos bewirken. Grundsätzlich gibt es drei Basisvarianten von externen Backupkonzepten. Natürlich sind Mischformen möglich.

2.6.1 Kaltes Backup

Diese Variante ist die kostengünstigste Lösung. Es handelt sich lediglich um die Bereitstellung eines Raumes in einem anderen Gebäudekomplex in der erforderlichen Größe und mit Anbindung von infrastrukturellen Einrichtungen, wie z.B. Klimaanlage, Doppelboden, Netzzuleitung usw. Bei einer kalten Lösung ist von einer Beschaffung der kompletten Hardware auszugehen. Die Beschaffung der Ersatzgeräte muss dabei sehr genau geplant werden, um die Wiederanlaufzeit angemessen genau bestimmen zu können. Steht kein Raum zur Verfügung, stellen die mobilen Ausweichrechenzentren eine andere Möglichkeit dar. Die Investitionskosten für eine solche Variante sind relativ gering, im Falle der tatsächlichen Nutzung sind aber hohe Mietkosten zu kalkulieren. Zur Wiederanlaufzeit muss zusätzlich die Anfahrts- u. Aufstelldauer eingerechnet werden. Der Nachteil der kalten Rechenzentren ist die lange Wiederanlaufzeit (14-30 Tage).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10 Schema eines kalten Ausweichrechenzentrums

2.6.2 Warmes Backup

Beim warmen Rechenzentrum ist zusätzlich kompatible Hardware bereitgestellt. Als warmes Backup kann beispielsweise das eigene Testrechenzentrum oder das RZ eines anderen Standorts, der über kompatible Hard- und Software verfügt. In diesem Fall ist ein enger und regelmäßiger Abstimmungsprozess erforderlich. Schon marginale Systemänderungen können gravierende Folgen haben. Es ist empfehlenswert die Nutzung vertraglich zu regeln, damit bei einem längeren K- Fall keine Auseinandersetzungen auftreten. Die Vorteile dieser Lösung sind die kürzere Wiederanlaufzeit (1-14 Tage). Es gibt auch Anbieter von kompletten mobilen Ausfallrechenzentren.

2.6.3 Heißes Backup

Diese Variante bringt die größte Risikominderung und schnellste Wiederanlaufzeit, sie ist jedoch auch die kostenintensivste Lösung. Hier wird ein redundantes Rechenzentrum mit kompletter Hardware vorgehalten. Eine Rechner- Rechner- Koppelung mit einem permanenten Datenabgleich ist dabei erforderlich. [2, 3]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11 Schema eines heißen Ausweichrechenzentrums

3 Analyse verschiedener Lösungsansätze

3.1 Entwicklung einer Word u. Excel Dokumentation

Die Realisierung einer Notfalldokumentation mit Textverarbeitungs- oder

Tabellenkalkulationsprogrammen erscheint zu Beginn am einfachsten. Man benötigt keine speziellen Vorkenntnisse, Mitarbeiter müssen nicht in die Bedienung eines neuen Systems eingeschult werden und meistens ist die schon bestehende Dokumentation in solchen Textsystemen abgelegt. Das führt zu einer gewissen Scheu den Bestand „umzukrempeln“ und bisher mühevoll Erarbeitetes nicht mehr zu verwenden. Zur Erstellung eines solchen Systems ist kein großartiges Datenbankdesign notwendig, daher ist kurzfristig gesehen kein großer Aufwand zu betreiben. Jedoch langfristig gesehen, bei Wachstum des Systems wird die Handhabung und Wartung unüberschaubar. Zudem ist es schwierig einen zentralen Informationsknotenpunkt aufrechtzuerhalten. Eine zusätzliche Wartung der HTML- Sourcen und Textdokumente ist notwendig. Da keine einheitlichen Datenstrukturen vorliegen, muss zwar kein festes Schema eingehalten werden, aber die automatisierte Auswertung in Form eines Notfallhandbuchs existiert nicht. Ein Notfallhandbuch, welches mit Textverarbeitungsprogrammen erstellt wurde, bietet wenig Spielraum hinsichtlich Redundanz und Wartungsaufwand. Beinhaltet das Handbuch viel redundante Information, so steigt der Wartungsaufwand ernorm an. Enthält das Handbuch wenig redundante Information, dann wird die Übersichtlichkeit darunter leiden, da wichtige Zuordnungen nicht doppelt ausgeführt werden können.

3.2 Entwicklung einer Datenbankapplikation

Die Eigenentwicklung einer angepassten und maßgeschneiderten Lösung bietet natürlich hohe Performance und wenn die Kundenwünsche dementsprechend in der Planungsphase berücksichtigt wurden auch eine hohe Akzeptanz der Mitarbeiter. Bei einer angepassten Lösung sind keine Funktionen implementiert, die nur selten bis gar nicht verwendet werden.

Ein eindeutiger Nachteil dieser Lösungsvariante ist ohne Zweifel der hohe Arbeitsaufwand in der Planungs-, Design- u. Implementierungsphase. Wenn Änderungen an der Datenbank notwendig sind oder Probleme auftauchen ist es notwendig, dass im Haus Spezialisten mit dem nötigen Know- How in DB- und Applikationsentwicklung zur Verfügung stehen. Im Endeffekt sind die Vorteile gegenüber einer Standardsoftware bald ausgeschöpft, denn der Wartungsaufwand der Notfalldaten ist nicht kleiner als bei einer Standardsoftware.

[...]

Ende der Leseprobe aus 76 Seiten

Details

Titel
Erstellung und Einführung eines Notfallkonzeptes im IT-Bereich eines Mittel- bis Großunternehmens
Hochschule
Fachhochschule Salzburg
Note
1
Autor
Jahr
2000
Seiten
76
Katalognummer
V185448
ISBN (eBook)
9783656982739
ISBN (Buch)
9783867463430
Dateigröße
1369 KB
Sprache
Deutsch
Schlagworte
erstellung, einführung, notfallkonzeptes, it-bereich, mittel-, großunternehmens
Arbeit zitieren
Dipl.Ing.(FH) Anton Gruber (Autor:in), 2000, Erstellung und Einführung eines Notfallkonzeptes im IT-Bereich eines Mittel- bis Großunternehmens, München, GRIN Verlag, https://www.grin.com/document/185448

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Erstellung und Einführung eines Notfallkonzeptes im IT-Bereich eines Mittel- bis Großunternehmens



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden