Hochverf¼gbare Referenz-Architekturmodelle

69
Hochverfügbare Referenz-Architekturmodelle Erstellt von AvailabilityPlus GmbH Berlin Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: [email protected] Internet: https://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2012

Transcript of Hochverf¼gbare Referenz-Architekturmodelle

Page 1: Hochverf¼gbare Referenz-Architekturmodelle

Hochverfügbare Referenz-Architekturmodelle

Erstellt von AvailabilityPlus GmbH Berlin

Bundesamt für Sicherheit in der InformationstechnikPostfach 20 03 6353133 BonnTel.: +49 22899 9582-0E-Mail: [email protected]: https://www.bsi.bund.de© Bundesamt für Sicherheit in der Informationstechnik 2012

Page 2: Hochverf¼gbare Referenz-Architekturmodelle

DokumentenhistorieDatum Version Beschreibung Autoren

09.02.11 0.02 Erste Version Tobias Goldschmidt

31.03.11 0.22 Content Update Tobias GoldschmidtDr. Günther Hoffmann

30.05.11 0.36 Struktur-Überarbeitung und Content Update

Tobias Goldschmidt

08.08.11 0.59 Struktur und Content Update Günther Hoffmann

29.08.11 0.78 Methodik Sebastian KnebelDr. Günther Hoffmann

30.09.11 0.89 Content Update Tobias GoldschmidtDr. Günther Hoffmann

25.10.11 0.95 Barrierefreiheit, Struktur-Überarbeitung und Content Update

Tobias Goldschmidt

30.5.12 0.99 Inhaltliche Überarbeitung insb. unter Berücksichtigung der neuen Struktur der Referenz-Architekturen, Reduzierung der Komplexität durch löschen komplexer Grafiken

Daniel Radünz Sebastian KnebelDr. Günther Hoffmann

22.8.12 1.01 Umarbeitung der Kapitel 5,6,7 nach Maßgabe des Projekttreffen #11. Kapitel 7 wird ausgelagert in ein eigenständiges Dokument.

Dajana Alsen

14.09.12 1.07 Überarbeitung unter Berücksichtigung der Kommentare von Frau Simons-Felwor und der Kommentare aus V0 99

Dr. Günther Hoffmann

20.11.12 1.12 Überarbeitung unter Berücksichtigung der Kommentare aus Protokoll 12.11.12

Dr. Günther Hoffmann

3.12.12 1.14 Überarbeitung unter Berücksichtigung der Kommentare aus den Emails vom 23.11.12 und 3.12.12

Dr. Günther Hoffmann

Page 3: Hochverf¼gbare Referenz-Architekturmodelle

QualitätssicherungDatum Version Status Freigabe durch

09.02.11 0.02 Pre-Release Diskussionsstand Dr. Günther Hoffmann

31.03.11 0.22 Pre-Release Diskussionsstand, nur zur projektinternen Verwendung für MS2

Dr. Günther Hoffmann

31.05.11 0.36 Pre-Release Diskussionsstand, nur zur projektinternen Verwendung für MS3

Dr. Günther Hoffmann

08.08.11 0.59 Pre-Release Diskussionsstand Keine Freigabe

29.08.11 0.78 Pre-Release Diskussionsstand, nur zur projektinternen Verwendung für MS3 nach CR1

Sebastian KnebelDr. Günther Hoffmann

30.5.12 0.99 Arbeitsdokument / Pre-release Keine Freigabe

22.8.12 1.01 Arbeitsdokument / Pre-release

Risikomanagement beachten

Dr. Günther Hoffmann

20.11.12 1.12 Arbeitsversion

4.12.12 1.14 Arbeitsversion

Bundesamt für Sicherheit in der Informationstechnik 3

Page 4: Hochverf¼gbare Referenz-Architekturmodelle

Inhaltsverzeichnis

Inhaltsverzeichnis1 Einleitung....................................................................................................................................71.1 Inhalte und Ziele................................................................................................................................8

1.2 Vorgehensweise für den Transfer in die Praxis..................................................................................9

1.3 Grundlegende Begriffe....................................................................................................................101.3.1 Architektur.................................................................................................................................101.3.2 Unternehmensarchitektur nach CobiT 4.1..................................................................................101.3.3 IT-Architektur nach ITIL............................................................................................................101.3.4 Service-Architektur nach ITIL....................................................................................................111.3.5 IT-Services..................................................................................................................................111.3.6 Reifegrad und Potential..............................................................................................................12

2 Architekturmodelle...................................................................................................................132.1 Einleitung........................................................................................................................................13

2.2 Architekturmodell im Kontext des HV-Kompendium.....................................................................152.2.1 Geschäftsprozesse......................................................................................................................162.2.2 IT-Dienstleistungen....................................................................................................................172.2.2.1 Höherwertige IT-Services / IT-Architektur............................................................................................172.2.2.2 Unterstützende IT-Services / It-Service-Architektur..............................................................................182.2.2.3 Basis Services / IT-Ressourcen..............................................................................................................18

2.3 Referenz-Architekturen: Theorie und Praxis...................................................................................18

2.4 Referenz-Architekturen in Architektur-Modellen............................................................................20

3 Übersicht über den Architekturkatalog.....................................................................................21

4 Notation und Nomenklatur........................................................................................................234.1 Allgemeine Architekturinformationen.............................................................................................234.1.1 Architekturattribute....................................................................................................................254.1.2 Design Prinzipien für HV-Architekturen....................................................................................30

4.2 Zuverlässigkeits-Blockdiagramme (RBD – Reliability Block Diagram).........................................32

4.3 Architekturskizze für die Techniksäule (Netzdiagramm).................................................................32

4.4 Architekturskizze für die Organisationssäule (Organisationsarchitektur)........................................334.4.1 Kundenanforderungen (I 1)........................................................................................................354.4.2 IT-Dienstleistung (I 2)................................................................................................................354.4.3 Standard-orientierte Organisationsarchitektur (I 3)....................................................................354.4.4 Gewachsene Organisationsarchitektur (I 4)................................................................................384.4.5 Service Base (I 5).......................................................................................................................38

4.5 Architekturbeschreibung.................................................................................................................38

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels..........405.1 Grundlagen der Methode.................................................................................................................40

5.2 Zielsetzung und Abgrenzung...........................................................................................................40

5.3 Die Methodik in Schritten...............................................................................................................41

5.4 HV Referenzarchitekturen Formularvorlage....................................................................................455.4.1 Beschreibungshinweise..............................................................................................................455.4.2 Architekturskizze........................................................................................................................475.4.3 Reliability Block Diagram (RBD)..............................................................................................505.4.4 Anforderungen an die Architektur..............................................................................................525.4.5 Merkmale der Architektur..........................................................................................................535.4.6 Unterstützung der HV-Prinzipien durch Architekturmerkmale ..................................................54

4 Bundesamt für Sicherheit in der Informationstechnik

Page 5: Hochverf¼gbare Referenz-Architekturmodelle

Inhaltsverzeichnis

5.4.7 Checkliste zur Feststellung der aktuellen Potentialstufe.............................................................595.4.8 Optimierungspotential für die nächst höhere Potentialstufe.......................................................605.4.9 Zusammenfassung......................................................................................................................62

5.5 Orchestrierung.................................................................................................................................65

6 Operative Unterstützung ..........................................................................................................66

7 Abkürzungsverzeichnis.............................................................................................................68

8 Glossar......................................................................................................................................69

9 Literaturverzeichnis..................................................................................................................73

AbbildungsverzeichnisAbbildung 1: Die Modellbereiche des Metamodells der Rahmenarchitektur IT Steuerung Bund... .13Abbildung 2: 3-Ebenen-Service-Modell des BSI...............................................................................14Abbildung 3: Einfaches generisches Architekturmodell....................................................................15Abbildung 4: Einfaches Architekturmodell – Zielemodell, technische und organisatorische Unterstützung.....................................................................................................................................16Abbildung 5: Beispiel eines differenzierten Architekturmodells.......................................................19Abbildung 6: Exemplarische RBD Darstellung einer Speicherarchitektur........................................32Abbildung 7: Exemplarisches Netzdiagramm einer Speicherarchitektur...........................................33Abbildung 8: Exemplarische Vorlage zur Erfassung einer Organisationsarchitektur ......................34Abbildung 9: Darstellung von Prozesskategorien mit enthaltenen Prozessgebieten..........................37Abbildung 10: Exemplarische Prozesskategorie „Service Operation“ nach ITIL V3. ......................38Abbildung 11: Schematisches Vorgehen zur Definition von IT-Zielen für das Ableiten einer IT-Architektur..........................................................................................................................................40Abbildung 12: Schema zur Ableitung einer Architektur....................................................................42Abbildung 13: Architekturskizze Netzwerk Potentialstufe 2.............................................................49Abbildung 14: Reliability Block Diagram Netzwerk Potentialstufe 2...............................................51

TabellenverzeichnisTabelle 1: Übersicht über Anteile der Systemarchitektur des Architekturkataloges .........................22Tabelle 2: Übersicht über Anteile der Organisationsarchitektur des Architekturkataloges................22Tabelle 3: Formularvorlage für die Beschreibung von HV Architekturmodellen..............................24Tabelle 4: Merkmale von HV-Referenz-Architekturen .....................................................................30Tabelle 5: HV-Architekturprinzipien und deren Zuordnung zu Potentialstufen................................31Tabelle 6: Methodentabelle zu Anforderungen, Verfügbarkeitsklassen, Potentialstufen und

Merkmalen ......................................................................................................................43Tabelle 7: Exemplarisch ausgefüllte Formularvorlage für die Beschreibung des HV

Architekturmodells Netzwerk Potentialstufe 2................................................................46Tabelle 8: Angewendete Module des IT-Grundschutzes in Potentialstufe 2......................................52Tabelle 9: Technische Merkmale der Potentialstufe 2........................................................................54Tabelle 10: Zuweisung der Merkmale der Potentialstufe 2 zu den HV-Prinzipien............................55Tabelle 11: Zuweisung der Maßnahmen der Potentialstufe 2 zu den HV-Prinzipien.........................56Tabelle 12: Umzusetzende Bausteine aus dem BSI-Grundschutz......................................................56Tabelle 13: Maßnahmen aus CobiT 4.1 in Potentialstufe 2................................................................58Tabelle 14: Checkliste der Potentialstufe 2........................................................................................59Tabelle 15: Optimierungspotential für die nächst höhere Potentialstufe............................................61Tabelle 16: Prägende Merkmale der Architektur................................................................................63

Bundesamt für Sicherheit in der Informationstechnik 5

Page 6: Hochverf¼gbare Referenz-Architekturmodelle

Inhaltsverzeichnis

Tabelle 17: Monitoringprozesse der Potentialstufe 2........................................................................64Tabelle 18: Exemplarische Anforderungen an eine Werkzeugunterstützung ....................................67Tabelle 19: Abkürzungsverzeichnis....................................................................................................68Tabelle 20: Glossar.............................................................................................................................72

6 Bundesamt für Sicherheit in der Informationstechnik

Page 7: Hochverf¼gbare Referenz-Architekturmodelle

Einleitung

1 EinleitungDie Innovationsfähigkeit und Sicherstellung eines nachhaltigen Geschäftsbetriebs von öffentlichen Einrichtungen, sowie die Wettbewerbs- und Überlebensfähigkeit von Unternehmen ist in zunehmendem Maße von Informationstechnologie (IT)-gestützten Prozessen abhängig. Dies gilt insbesondere für den Betrieb und Erhalt kritischer Infrastrukturen. IT ist ein entscheidender Faktor, um Organisationsstrukturen und Abläufe zu optimieren. Geschäftsprozesse bauen heute maßgeblich auf IT-Services auf. Diese wiederum sind abhängig von konkreten Komponenten und deren Verschaltung sowie den betreuenden Personen und Unterstützungsprozessen. Konsequenterweise unterliegen damit Geschäftsprozesse, denselben Gefährdungen, die auch für IT-Services und deren konstituierende Komponenten gelten. Das Gefährdungspotential reicht dabei von Ausfällen der Software, Hardware, Infrastruktur, mangelhaft oder nicht implementierte Prozesse, über gesteuerte Angriffe auf die IT, Naturkatastrophen bis hin zu Fehlhandlungen der aktiven Personen.Somit hat die Architektur der IT-Landschaft, bestehend aus den technischen und organisatorischen Säulen, die Qualität einzelner IT-Services, die Verfügbarkeit einzelner Komponenten, deren Verschaltung sowie die Reife der unterstützenden IT-Prozesse eine direkte Auswirkung auf die Sicherstellung des effizienten und nachhaltigen Geschäftsbetriebs sowie der Verfügbarkeit der unterstützen Geschäftsprozesse.Trotz der zentralen Bedeutung von IT in öffentlichen Einrichtungen und Unternehmen fehlt bisher häufig

1. die vertikale Integration und Koordination von IT und Geschäftszielen sowie deren Planung und gezielte Steuerung,

2. die horizontale Integration und Koordination der technischen und organisatorischen Leistungsfelder auf Basis generischer Referenz-Prozess-Modelle,

3. die Unterstützung dieser beiden Kernfelder durch geeignete Methoden, Werkzeuge und Bibliotheken.

Um dieser Problematik entgegenzutreten, werden innerhalb dieser Ausarbeitung generische Architekturmodelle, sog. Referenz-Architekturen, sowohl für die technischen als auch für die organisatorischen Leistungsfelder entwickelt. Diese sollen die Grundlage und den Ausgangspunkt für die konzeptionelle Entwicklung höherwertiger IT-Services bilden, insbesondere für die Zieldefinition Hochverfügbarkeit. Die zur Adressierung der aufgeführten Herausforderungen notwendigen Steuerungsprozesse erfahren idealerweise eine Orientierung an internationalen Standards, wie z.B. ITIL V3und CobiT 4.1 . Mit dieser Ausrichtung gehen transparente IT-Prozesse einher, mit definierten Zielen und messbaren Kriterien, die über geeignete Prüfverfahren einem Prozess zur Qualitätssteuerung zugeführt werden können und in einem kontinuierlichen Verbesserungsprozess münden. Die hier relevanten Standards sind international mit dem Begriff „IT-Governance“ belegt. IT-Governance Verfahren decken jedoch überwiegend den organisatorischen Anteil des IT-Managements ab.

Bundesamt für Sicherheit in der Informationstechnik 7

Page 8: Hochverf¼gbare Referenz-Architekturmodelle

1 Einleitung

1.1 Inhalte und Ziele

Im vorliegenden Dokument werden für ausgewählte Funktionsbereiche Architekturen in einer homogenen Notation für unterschiedliche Verfügbarkeitsszenarien erstellt. Hierzu wird exemplarisch auf Architekturskizzen aus den technischen Bereichen Netzwerk und Speichertechnologien sowie dem organisatorischen Bereich IT-Operation des BSI zurückgegriffen, welche nach Experteneinschätzung bezüglich der Verfügbarkeitsabsicherung einen Best-Practice-Ansatz darstellen. Die vorgestellten HV-Architekturen sollen einen IT-Architekten in Hinblick auf die Hochverfügbarkeit in die Lage versetzen, die für seine Zwecke geeigneten Architekturen auszuwählen, erforderliche Aspekte aus dem Bereich Hochverfügbgarkeit zu berücksichtigen und diese entsprechend seinen Anforderungen anzupassen und mit konkreten Werten zu parametrisieren.In der vorliegenden Studie werden sowohl technische als auch organisatorische Aspekte von IT-Architekturen beleuchtet. Beide Teilbereiche werden zu IT-Services zusammengefasst, welche sich zu einem ganzheitlichen Architekturmodell zusammenfügen (Kapitel 2 Architekturmodelle). Die technischen Architekturen werden zum einen in der üblichen Notation eines Netzdiagramms visualisiert. Zusätzlich werden diese Architekturen durch Zuverlässigkeits-Blockdiagramme (Reliability Block Diagramme - RBD) spezifiziert. Dies erlaubt die Berechnung der Verfügbarkeit einer Architektur und unterstützt die Quantifizierung und damit Bewertbarkeit und Steuerbarkeit. Zusätzlich erlaubt die Modellierung in einem RBD die Analyse der HV-Architektur hinsichtlich Schwachstellen, z.B. Single-Points-of-Failure (SPoF). Organisatorische Architekturen werden in Form hierarchischer Schichtenmodelle vorgestellt, welche Abhängigkeiten aufzeigen zwischen Anforderungen, Prozessgebieten und Ressourcen (Kapitel 4 Notation und Nomenklatur).Das übergeordnete Ziel ist, die Messung der Leistung eines IT-Services zu unterstützen und damit eine Bewertung zu ermöglichen. Eine Leistungssteigerung eines IT-Services sollte sich damit in der Verbesserung dessen Mehrwertes nachweisen lassen. Mit dem Ziel der Optimierung der Verfügbarkeit, sollte die Qualitätssteigerung mit einer Steigerung der Verfügbarkeit einhergehen. Dies muss nicht notwendiger Weise durch den Nachweis erhöhter Verfügbarkeitszeiten geschehen, sondern kann auch auf der Basis eines qualitativen Leistungsvergleiches erfolgen. Somit existiert ergänzend zu der quantitativen IT-Service-Bewertung ein qualitatives Maß, welches die Realisierung eines nachhaltigen und hochverfügbaren Betriebs von IT-Services und das professionelle Zusammenspiel von Verantwortlichen für Systeme, Netze, Infrastruktur, Administration, Wartung, Monitoring sowie eine zeitnahe Reaktion auf Anfragen und Ereignisse in fünf Ausprägungsstufen beschreibt (Kapitel 5 Methodik zur Entwicklung und Bewertung vonArchitekturen Anhand eines Beispiels).Durch diese Vorgehensweise soll ein Hilfsmittel geschaffen werden, um der wachsenden Komplexität professioneller IT-Landschaften zu begegnen, indem innerhalb der Gesamtarchitektur standardisierte Teile gekapselt und im Sinne von Best-Practices einer zielorientierten Bewertung und Service-Orchestrierung zugeführt werden.

8 Bundesamt für Sicherheit in der Informationstechnik

Page 9: Hochverf¼gbare Referenz-Architekturmodelle

Einleitung

1.2 Vorgehensweise für den Transfer in die Praxis

Im vorliegenden Dokument wird ein Gesamtkonzept vorgestellt, welches beim ganzheitlichen IT Management einer Behörden- oder Unternehmens-IT Landschaft unterstützen soll. Die Teilbereiche

1. Technik und 2. Organisation

werden in einem Wirkzusammenhang betrachtet. Es wird eine komplexe Aufgabenstellung bearbeitet. Bislang separat oder gar nicht betrachtete Einzelaspekte in der IT Steuerung werden einer ganzheitlichen Sicht zugeführt, die nachfolgende Kernbereiche integriert:

1. die technischen Aspekte,2. die organisatorischen Aspekte,3. die Zusammenführung beider Aspekte in IT-Services sowie4. die Bündelung und Steuerung von IT-Services vor dem Hintergrund konkreter Ziele wie z.B.

Hochverfügbarkeit, Sicherheit, Effizienz, Agilität oder Standardisierung.Die vorgelegten Referenz-Architekturen können nur als Startpunkt für eigene Überlegungen dienen. Abhängig von den Anforderungen und der Zielsetzung der Behörde oder des Unternehmens werden sich in der Praxis andere als die hier vorgestellten Architekturen als optimal erweisen. Es werden jedoch Anhand der vorgestellten Vorgehensweise Architekturen abgeleitet und in Beispielen plausibilisiert. Der Leser soll damit in die Lage versetzt werden, für seine individuelle Anforderung Ergebnisse ableiten zu können. Ebenso soll der Leser in die Lage versetzt werden, höherwertige IT-Architekturen aus einzelnen Bausteinen, nach Art eines Baukastensystems, zusammenzusetzen oder zu orchestrieren. Vor dem Hintergrund eines in der Praxis uneinheitlich gehandhabten Sprachgebrauchs, sollten die vorgestellten Konzepte, insbesondere das in Abbildung 3 vorgestellte Architekturmodell, an den Sprachgebrauch des Nutzers angepasst werden. In der vorliegenden Studie werden Referenz-Architekturen mit dem Zielfokus „Verfügbarkeit“ entwickelt, daher die Bezeichnung HV-Architekturen, synonym für Hochverfügbarkeits-Architekturen. In der unternehmerischen Praxis werden ggf. andere, ergänzende oder wechselnde Ziele priorisiert. Häufig werden implizit sich widersprechende Ziele formuliert, wie z.B. hohe Verfügbarkeit und enge Budgetgrenzen oder Sicherheit und ubiquitärer Zugriff auf die IT-Landschaft. Das in der vorliegenden Studie präsentierte Vorgehensmodell soll bei der transparenten Diskussion, Standardisierung und Parametrisierung der zu entwickelnden Architekturen unterstützen. Im vorliegenden Dokument kann erwartet werden:

• Methode zur qualitativen Bewertung von Organisationsarchitekturen• Methode zur qualitativen Bewertung von Systemarchitekturen• Methode zur quantitativen Bewertung von Systemarchitekturen, konkret Berechnung des

Verfügbarkeitspotentials A einer Verschaltung• Bibliothek bestehend aus Referenzarchitekturen für ausgewählte IT-Domänen

Im vorliegenden Dokument kann nicht erwartet werden:• allgemeingültige Aussagen zu optimalen System- oder Organisationsarchitekturen

Der Einsatz eines Werkzeugs ist nicht zwingend erforderlich zur Unterstützung der in diesem Dokument vorgestellten Vorgehensweise. Mit einem handelsüblichen Tabellenkalkulations-Werkzeug können die meisten Tabellen und Darstellungen nachvollzogen werden. Der Einsatz eines Werkzeugs wie z.B. SHIP-IT erleichtert jedoch die Datenerfassung, Analyse und Darstellung erheblich und trägt somit, insbesondere bei der Bestimmung quantifizierbarer Verfügbarkeiten, zur Effizienzsteigerung bei der IT-Steuerung bei. Vgl. Kapitel „6 Operative Unterstützung „

Bundesamt für Sicherheit in der Informationstechnik 9

Page 10: Hochverf¼gbare Referenz-Architekturmodelle

1 Einleitung

1.3 Grundlegende Begriffe

In diesem Kapitel werden grundlegende Begriffe eingeführt, um das notwendige Verständnis für die im weiteren Verlauf vorgestellten HV-Architekturmodelle zu gewährleisten und eine einheitliche Terminologie zu schaffen. Ergänzend wird auf die Dokumente [BSI Service-Modell] und [BMI - ITDienste] verwiesen.Der Begriff Architektur oder IT-Architektur ist in der IT zwar etabliert, häufig wird der Begriff jedoch ohne ein gemeinsames Verständnis eingesetzt. Eine allgemeingültige Definition ist bislang nicht etabliert. Unterschiedliche Zielgruppen und Einzelpersonen stützen sich häufig auf unterschiedliche Definitionen. Zudem wird der Architekturbegriff häufig weiter differenziert wie z.B. in Informations-Architektur, IT-Service-Architektur, Sicherheits-Architektur, Anwendungs-Architektur, Unternehmens-Architektur, Software-Architektur mit ähnlich unscharfen Definitionen. Um dennoch in der vorliegenden Dokumentation einen einheitlichen Sprachgebrauch zu etablieren orientieren sich die Autoren, soweit möglich, an bekannten Standards und fassen wie folgt zusammen:1.3.1 ArchitekturEine Architektur beschreibt nach [ISO/IEC 42010:2007] die allgemeine Ordnung eines Systems. Diese ist durch die Systemkomponenten mit der Beschreibung ihrer gegenseitigen Beziehungen und zur Umgebung sowie durch die Prinzipien, welche den Entwurf als auch die Weiterentwicklung des Systems im Laufe der Zeit steuern und kontrollieren, gekennzeichnet.Die Open Group greift mit dem Open Group Architecture Framework (TOGAF) diese Definition auf und erweitert sie. Dabei hat der Begriff „Architektur“ abhängig vom Kontext zwei Bedeutungen:

1. Eine formale Beschreibung oder ein detaillierter Plan des Systems auf Komponentenebene als Leitlinie für die Implementierung.

2. Die Struktur der Komponenten, deren Beziehungen untereinander sowie die Prinzipien und Richtlinien, die das Design und die Weiterentwicklung der Komponenten im Laufe der Zeit bestimmen.

1.3.2 Unternehmensarchitektur nach CobiT 4.1Das IT Governance Institute führt mit dem Control Objectives for Information and related Technology [CobiTv4.1] den Begriff der Unternehmensarchitektur für IT ein. Eine Unternehmensarchitektur wird dabei von definierten Prozessen, welche Informationen liefern, Anwendungen betreiben und Infrastruktur sowie Personal für den erfolgreichen Betrieb benötigen, geprägt. Voraussetzung für die erfolgreiche Erbringung von Services zur Unterstützung der Unternehmensstrategie, sind klar definierte Verantwortlichkeiten und Vorgaben durch das Kerngeschäft (den Kunden) sowie ein präzises Verständnis über den durch die IT (den Dienstleister) zu deckenden Bedarf. Diese Vorgaben führen zur Festlegung der IT eigenen Ziele, welche IT-Ressourcen und deren Leistungen definieren und für eine erfolgreiche Erfüllung, der sich aus der Strategie ergebenden Aufgaben, erforderlich sind. Diese Ressourcen bilden gemeinsam mit den Prozessen die IT-Sicht auf die Unternehmensarchitektur.1.3.3 IT-Architektur nach ITILUnter IT-Architektur wird nach [ITILv3 - Service Design] die Struktur eines Systems oder IT-Service einschließlich der Beziehungen zwischen den Komponenten untereinander und der Beziehungen zur zugehörigen Umgebung verstanden. Die IT-Architektur schließt auch Standards und Leitlinien ein, an denen sich das Design und die Entwicklung des Systems ausrichten. Damit wird die komponentenbasierte Sichtweise von Architekturen um die prozessorientierte Sichtweise ergänzt und somit eine wesentliche Brücke zwischen den technischen und organisatorischen Potentialen etabliert. Vgl. hierzu auch [BMI - IT Dienste], [BSI Service-Modell] sowie

10 Bundesamt für Sicherheit in der Informationstechnik

Page 11: Hochverf¼gbare Referenz-Architekturmodelle

Einleitung

[Rahmenarchitektur].Nach ITIL v3 sind dabei folgende organisatorische Prozesse direkt involviert:

• Service Level Management (SLM),• Slogue Management (SCM),• Capacity Management (CAM),• Availability Management (AM),• IT-Service Continuity Management (ITSCM),• Information Security Management (ISM) sowie• Supplier Management (SM).

1.3.4 Service-Architektur nach ITILDie Service-Architektur gilt nach [ITILv3] als strategisches Tool. Sie definiert Aufbau und Gefüge von Computern, Netzwerken, Anwendungen und anderer IT-Ressourcen im Hinblick auf eine businessorientierte Service-Organisation. Damit werden Services kundenspezifisch und kostenoptimal erbracht. Die hierarchische Modellierung der IT-Ressourcen erlaubt die Realisierung von wieder verwendbaren Teilservices sowie die Reduzierung von Komplexität. Die Service-Architektur gibt die Struktur der Services vor und bildet den Grundstein des Service Katalogs mit Preismodell und damit auch die Basis für ein Service Level Agreement (SLA).1.3.5 IT-ServicesEin IT-Service ist nach [ITILv3] eine Dienstleistung, die für einen oder mehrere Kunden von einem IT-Service Provider bereitgestellt wird. Ein IT-Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Geschäftsprozesse des Kunden. Ein IT-Service besteht aus einer Kombination von Personen, Prozessen und Technologien und sollte über ein Service Level Agreement (SLA) definiert werden. Synonym zu IT-Service wird oft auch Service verwendet. Ein IT-Service besteht aus vier Elementen in zwei Teilbereichen:

a) Teilbereich: Technische Leistungen (vgl. Abbildung 3, technischer Anteil)1) Entitäten: ein Service setzt sich zusammen aus mindestens einer, typischerweise

mehreren Entitäten, die voneinander abhängig sind und untereinander verbunden sind.2) Logik: Ein Service kennt die Logik/ Prozesse, die in einem Netzplan nicht abgebildet

sind, jedoch zur Entwicklung eines Verfügbarkeitsmodells, insbesondere für die Verschaltung der Entitäten, unerlässlich sind, zum Beispiel▪ Prozesse, welche die Entitäten in bestimmter Reihenfolge ansprechen▪ Regeln, die bestimmen wie viele Komponenten funktionsfähig sein müssen

3) Verschaltung: Ein Service kennt die Verschaltung seiner konstituierenden Entitäten untereinander.

b) Teilbereich: Prozessgebiete (vgl. Abbildung 3, organisatorischer Anteil)4) Organisatorische Unterstützung durch Prozesse

Der organisatorische Anteil eines IT-Services kann aus folgenden Elementen bestehen: • Referenzmodell: Ein Referenzmodell besteht aus Prozesskategorien.• Prozesskategorie: Eine Prozesskategorie besteht aus Prozessgebieten.

• Prozessgebiet: Ein Prozessgebiet kann über Indikatoren quantifiziert werden. Synonym wird ein Indikator auch als Key Performance Indicator (KPI) oder Key Goal Indicator (KGI) bezeichnet. Vgl. hierzu auch [BMI - IT Dienste].

• Indikatoren innerhalb eines Prozessgebietes können optional in einem Control gruppiert werden. Ein Control wohnt innerhalb eines Prozessgebietes. Ein Control stellt ein Ordnungsmerkmal dar.

• Reifegrad pro Prozessgebiet: Für jedes Prozessgebiet wird ein Reifegrad im Interval [1; 5] bestimmt.

Bundesamt für Sicherheit in der Informationstechnik 11

Page 12: Hochverf¼gbare Referenz-Architekturmodelle

1 Einleitung

1.3.6 Reifegrad und PotentialEin Reifegrad im Intervall [1;5] beschreibt die Prozessreife einzelner organisatorischer Prozesse über fünf Entwicklungsstadien (initial, wiederholbar, definiert, gesteuert und optimiert). Der aktuelle Zustand eines Prozesses wird unter Nutzung spezifischer Attribute der Reife in einem Reifegrad fixiert. Bei der Skalierung wird davon ausgegangen, dass sich Prozesse von einer initialen Ausgangslage zu einem optimierten Prozess entwickeln. Im vorliegenden Dokument beschreibt ein Potential im Intervall [1;5] das Entwicklungsstadium einer Organisations- und System-Architektur, ausgehend von Aktivitäten zur Steuerung und Kontrolle (von Behörden / Unternehmen).

12 Bundesamt für Sicherheit in der Informationstechnik

Page 13: Hochverf¼gbare Referenz-Architekturmodelle

Architekturmodelle

2 Architekturmodelle

2.1 Einleitung

Eine einheitliche oder standardisierte Vorgehensweise zur Beschreibung und/oder Ableitung von Architekturen existiert zum Zeitpunkt der Erstellung dieser Studie nicht. Unterschiedliche Behörden und Unternehmen nutzen unterschiedliche Architekturen. Dies vorausgeschickt, existieren Vorlagen (Architekturmodelle oder Frameworks) für unterschiedliche Ansprüche und Aufgabenbereiche. Ohne Anspruch auf Vollständigkeit oder Präferenz sind dies z.B. TOGAF, COSO, CobiT, ITIL, die BSI-Standards 100-1 bis 100-4 und die BSI Grundschutzkataloge. In der IT Steuerung Bund (vgl. [Rahmenarchitektur]) wird exemplarisch ein ganzheitliches Modell vorgestellt, welches sowohl IT als auch Bereiche mit direkter Wechselwirkung zur IT berücksichtigt, wie z.B. das Zielemodell, Geschäftsmodell, Dienstmodell, Technisches Modell und Informationsmodell.

In [BSI Service-Modell] wird das Drei-Ebenen-Service-Modell vorgestellt, welches den Fokus auf eine serviceorientierte Sichtweise legt.

Bundesamt für Sicherheit in der Informationstechnik 13

Abbildung 1: Die Modellbereiche des Metamodells der Rahmenarchitektur IT Steuerung Bund

Page 14: Hochverf¼gbare Referenz-Architekturmodelle

2 Architekturmodelle

Für Teilbereiche wie z.B. Sicherheit, existieren weitere Methodenrahmen zur Unterstützung der Zielableitung, Bewertung des Ist Zustandes und zur Entwicklung von Maßnahmen zur Reduzierung der Lücke zwischen Ist und Soll, wie z.B. BSI Grundschutz für IT Sicherheitsarchitekturen. Die Operationalisierung der Zielarchitektur muss jedoch in den meisten Fällen von der betreffenden Organisation eigenständig geleistet werden. Der Architekturbegriff muss daher differenziert und kontextabhängig betrachtet werden. In einem Unternehmen oder einer Behörde existiert nicht die Architektur, sondern es kommen gesteuert oder weniger gesteuert unterschiedliche Architekturansätze in unterschiedlichen Bereichen zum Einsatz, selten mit einer eindeutigen Referenz auf ein Architekturmodell. Auf einer groben Abstraktionsebene können meist drei Architekturbereiche identifiziert werden. Diese sind:

• Unternehmensarchitektur oder Zielemodell• ein oder mehrere Architekturbereiche, die sich mit der technischen Unterstützung

beschäftigen• ein oder mehrere Architekturbereiche, der sich mit der organisatorischen Unterstützung

beschäftigenTeilweise inkludiert die Unternehmensarchitektur, die technischen und organisatorischen Bereiche, wie z.B. in TOGAF.

14 Bundesamt für Sicherheit in der Informationstechnik

Abbildung 2: 3-Ebenen-Service-Modell des BSI

Page 15: Hochverf¼gbare Referenz-Architekturmodelle

Architekturmodelle

2.2 Architekturmodell im Kontext des HV-Kompendium

Unter Hinzuziehung des Servicegedanken lässt sich ein differenzierteres und dennoch weitgehend generisches Modell ableiten, welches Abhängigkeiten der Geschäftsprozessebene von IT-Dienstleistungen, sowie technischen und organisatorischen Aspekten berücksichtigt. [660cASA3]

Das Architekturmodell aus Abbildung 3 unterstützt die durchgängige Modellierung und Abbildung von Abhängigkeiten von der Geschäftsprozessebene bis auf Komponentenebene unter expliziter Bezugnahme sowohl auf die technische als auch organisatorische Unterstützungssäule, siehe Abbildung 4.

Bundesamt für Sicherheit in der Informationstechnik 15

Abbildung 3: Einfaches generisches Architekturmodell

Page 16: Hochverf¼gbare Referenz-Architekturmodelle

2 Architekturmodelle

Im Folgenden werden die Modellebenen aus Abbildung 3 und Abbildung 4 im Detail beschrieben.

2.2.1 GeschäftsprozesseGeschäftsprozesse erfordern zunehmend eine Unterstützung durch IT-Services oder werden durch diese erst ermöglicht. Informations- und Kommunikationsinfrastrukturen kommen somit

16 Bundesamt für Sicherheit in der Informationstechnik

Abbildung 4: Einfaches Architekturmodell – Zielemodell, technische und organisatorische Unterstützung

Page 17: Hochverf¼gbare Referenz-Architekturmodelle

Architekturmodelle

zunehmend Schlüsselrollen bei der Aufgabenerfüllung von Unternehmungen und behördlichen Organisationen zu, womit eine stetig wachsende Abhängigkeit von der IT und IT-Dienstleistungen einhergeht. Das HV-Kompendium des BSI widmet sich der Gestaltung von IT-Leistungen, deren Services hochverfügbar und in konstanter Qualität geliefert werden sollen.

Eine IT-Architektur beschreibt die IT in einer Organisation hinsichtlich ihrer Grundstrukturen und Regeln, die das dynamische Zusammenspiel aller Prozesse und Komponenten koordinieren. In einer HV-Architektur sind die Strukturen und Regeln so ausgelegt, dass die IT-Ressourcen nach den HV-Prinzipien (Tabelle 5 im Kapitel 4.1.2) optimiert ausgelegt werden. IT-Architekturen sollen hinsichtlich ihrer Verfügbarkeitseigenschaften skalierbar sein. D. h. es können IT-Architekturen im gleichen Funktionsbereich für unterschiedliche Verfügbarkeitsklassen existieren (z. B. DB-Server im Cluster- oder Standby-Betrieb). Anwendungsfälle (Use Cases) wie beispielsweise die Modellierung und die Bewertung von Potentialen, gilt es dabei abzudecken.

Geschäftsprozesse leiten sich aus den Geschäftszielen der Organisation ab. Geschäftsprozesse werden durch IT-Dienstleistungen unterstützt. IT-Dienstleistungen setzen sich aus IT-Services zusammen. IT-Services bestehen typischerweise aus einem technischen und einem organisatorischen Anteil. Die Anteilsverteilung kann dynamisch betrachtet werden. Somit kann ein IT-Service allein aus einem organisatorischen Anteil, z.B. „Incident Management“ oder allein aus einem technischen Anteil, z.B. „DNS Service“ bestehen. Ebenso wird eine praxistaugliche Mischform durch das Modell unterstützt, z.B. ein SAP Service, der sowohl eine technische Basis als auch ein eigenes Governance Modell mitbringt. IT-Services basieren auf Ressourcen wie Software, Hardware, Infrastruktur, Personal und IT-Organisation (SHIP-IT).

IT-Services können sich nach dem Lego-Prinzip hierarchisch zusammensetzen. Ein IT-Service in der Ebene der höherwertigen IT-Services, besteht aus einer Menge von IT-Services aus der darunterliegenden Ebene der unterstützenden IT-Services.

Die Einordnung eines IT-Services in die entsprechende Ebene (unterstützende oder höherwertige IT-Services) ist abhängig von der geschäftlichen Ausrichtung des jeweiligen Unternehmens. Beispielsweise wäre der IT-Service „Speichertechnologie“ eines Unternehmens, dessen Geschäftsausrichtung Speichertechnologie nicht adressiert, sondern lediglich zu Speicherung von Unternehmensdaten verwendet, innerhalb der Ebene der unterstützenden IT-Services einzuordnen. In einem Unternehmen, dessen Fokus beispielsweise die Vermarktung von Speichertechnologien darstellt, wäre dieser IT-Service innerhalb der Ebene der höherwertigen IT-Services, also den IT-Dienstleistungen, einzuordnen. Folglich werden IT-Services als IT-Dienstleistungen bezeichnet, wenn Sie einen Geschäftsprozess unmittelbar unterstützen (vgl. [BSI Service-Modell]).

2.2.2 IT-DienstleistungenEine IT-Dienstleistung ist eine logische, rein konzeptionelle Einheit, die einen definierten Umfang an funktionalen Anforderungen erfüllt (vgl. [Rahmenarchitektur]). Das Konzept des Dienstes wird zur Strukturierung des IT-Angebotes genutzt. Es ist weiterhin dazu geeignet Nachfrage auf einer groben Beschreibungsebene zu identifizieren und zu beschreiben, der einen Abgleich mit dem IT-Angebot erlaubt.2.2.2.1 Höherwertige IT-Services / IT-Architektur IT-Dienstleistungen sind IT-Services, die als „Business Enabler“ den Geschäftsprozessen unmittelbar einen Service anbieten und diese damit unterstützen oder ermöglichen. Eine IT-Dienstleistung wird über das Zusammenwirken einzelner IT-Services orchestriert, um so dem Geschäftsprozess eine Funktionalität zur Verfügung zu stellen. Basis für das Erbringen von IT-Services bilden die IT-Ressourcen. Das BSI unterscheidet IT-Services und IT-Dienstleistungen. IT-Services werden als IT-Dienstleistungen bezeichnet, wenn Sie einen Geschäftsprozess unmittelbar

Bundesamt für Sicherheit in der Informationstechnik 17

Page 18: Hochverf¼gbare Referenz-Architekturmodelle

2 Architekturmodelle

ermöglichen oder unterstützen. Die Definition schafft damit eine Hierarchie über IT-Dienstleistungen, IT-Services und Ressourcen, welche die Abhängigkeit der Geschäftsprozesse widerspiegelt (vgl. [BSI Service-Modell]).2.2.2.2 Unterstützende IT-Services / It-Service-ArchitekturEin unterstützender IT-Service wird als funktionale Dienstleistung eines Teilsystems, mit der ein Beitrag zur Funktion des Gesamtsystems geleistet wird, verstanden. Über das Zusammenwirken einzelner unterstützender IT-Services wird eine IT-Dienstleistung orchestriert, um dem Geschäftsprozess damit eine Funktionalität zur Verfügung zu stellen. Basis für das Erbringen von unterstützenden IT-Services bilden die IT-Ressourcen.2.2.2.3 Basis Services / IT-RessourcenFür die erforderlichen Arbeitsschritte innerhalb der (Geschäfts-)Prozesse werden unterschiedliche Hilfsmittel verwendet. Diese Ressourcen umfassen allgemein betrachtet auch „nicht-IT-Ressourcen“ wie beispielsweise allgemeine Handlungsanweisungen und Konzeptpapiere. Im HV-Kompendium werden nur die IT-Ressourcen betrachten, die sich aus Software, Hardware, Infrastrukturen, Personal und IT-Organisation zusammensetzen. Alle IT-Ressourcen dienen letztlich dazu, die erforderlichen Dienstleistungen zur Erbringung des Geschäftsprozesses zur Verfügung zu stellen.

2.3 Referenz-Architekturen: Theorie und Praxis

Um die Komplexität in der Praxis angetroffener IT-Landschaften erfassen zu können muss oft abstrahiert werden. Abstraktion ist dann hilfreich, wenn die Beherrschbarkeit von Komplexität gesteigert wird ohne die Ergebnistauglichkeit zu gefährden. Referenz-Architekturen können z.B. in den folgenden Szenarien (Use Cases) unterstützen:

1. Etablierung von Referenz-Architekturen innerhalb der Behörde oder des Unternehmens basierend auf einer Abstraktion bereits etablierter und bewährter Architekturen, z.B. zum Zweck der Standardisierung (Bottom-Up)

2. Nutzung von Referenz-Architekturen als Leitlinie zur Etablierung eigener angepasster Architekturen (Top-Down)

3. Abgleich vorhandener Architekturen mit Referenz-Architekturen zur Identifikation von Optimierungspotentialen (Benchmarking)

Eine Referenz-Architektur wird vor dem Hintergrund der Wiederverwendbarkeit von Strukturinformation für eine bestimmte Zielsetzung eingesetzt. Die genannten Szenarien können einander bedingen und zeitlich aufeinander folgen. Der Vorteil einer Referenz-Architektur besteht darin, dass die Aktivitäten im Rahmen des IT-Managements zielgerichtet, modular und steuerbar ablaufen können. Komplexität wird handhabbar. Unterschiedliche Zielgruppen und Akteure im Bereich der IT-Steuerung erhalten die Information, die Sie zur Durchführung Ihrer Tätigkeiten benötigen. Referenz-Architekturen sind somit ein Instrument zur ganzheitlichen IT-Steuerungen und zur Standardisierung.Bei weitergehender Betrachtung und unter Einbeziehung des in Abbildung 3 dargestellten Architekturmodells ermöglichen standardisierte Referenz-Architekturen die effiziente und transparente Unterstützung von Geschäftszielen. In einer idealisierten Vorgehensweise werden aus den Geschäftsanforderungen IT-Ziele abgeleitet, die durch standardisierte Referenz-Architekturen kosten-, funktions- und risikotransparent realisiert werden (Top-Down).In der Praxis werden häufiger „gewachsene“ IT-Landschaften auf unscharfe Anforderungen aus dem Geschäftsbetrieb stoßen, die mit kleiner werdenden Budgets zu realisieren sind. Hier können Referenz-Architekturen bei der Standardisierung und somit Effizienzsteigerung unterstützen, Abhängigkeiten und Wirkzusammenhänge transparent machen und somit die Leitplanken für die IT-

18 Bundesamt für Sicherheit in der Informationstechnik

Page 19: Hochverf¼gbare Referenz-Architekturmodelle

Architekturmodelle

Steuerung setzen.In der Praxis können häufig die folgenden Teilarchitekturen identifiziert werden,

• Unternehmensarchitektur• Facharchitektur• Anwendungsarchitektur• Systemarchitektur• Sicherheitsarchitektur• Organisationsarchitektur

die in Abbildung 5 im Architekturmodell verortet werden.

Bundesamt für Sicherheit in der Informationstechnik 19

Abbildung 5: Beispiel eines differenzierten Architekturmodells

Page 20: Hochverf¼gbare Referenz-Architekturmodelle

2 Architekturmodelle

Zur Klarstellung: In der Praxis trifft man selten die akademisch geprägte Top down Vorgehensweise an, die eine Gesamtarchitektur sowie Teilarchitekturen vorgibt, an der sich das Unternehmen/ die Behörde orientiert. Architekturen in der Praxis sind häufig gewachsen, durch ad hoc Lösungen für ad hoc Anforderungen evolviert und durch wahrgenommene pragmatische Teil- und Insellösungen geprägt. Prozesse sind überwiegend informell kommuniziert und selten in höherem Detailgrad dokumentiert. Abhängigkeiten zwischen Anforderungen, Geschäftsprozessen, IT und IT Organisation sind in den seltensten Fällen bekannt, dokumentiert oder analytisch zugänglich.

2.4 Referenz-Architekturen in Architektur-Modellen

Die Architektur-Modelle dienen als konzeptionelle Grundlage der Service-Modellierung zur konkreten Ausgestaltung von Services in der Praxis zur Erbringung von IT-Dienstleistungen. Dazu werden für den technischen Bereich Komponentenmodelle und im organisatorischen Bereich Referenzprozessmodelle zur Verfügung gestellt. Bei den Komponentenmodellen erfolgt die Orchestrierung von Subservices über Ressourcen-Komponenten zu einem technischen IT-Service. Bei den Prozessmodellen stehen organisatorische Abläufe zur Gestaltung und zum Betrieb von IT-Services orientiert an dem PDCA-Zyklus im Vordergrund. Die Kombination dieser Sichtweisen in einem ganzheitlichen methodischen Ansatz stellt die verlässliche Reproduzierbarkeit und Nachhaltigkeit von qualitativ hochwertigen Services zu einer bedarfsgerechten IT-Dienstleistung sicher.

20 Bundesamt für Sicherheit in der Informationstechnik

Page 21: Hochverf¼gbare Referenz-Architekturmodelle

Übersicht über den Architekturkatalog

3 Übersicht über den ArchitekturkatalogDer zur Verfügung gestellte Architekturkatalog umfasst die die Bereiche

1. Organisationsarchitektur und2. Systemarchitektur

Damit werden zwei Kernbereiche des in Kapitel 2.2 „Architekturmodell im Kontext des HV-Kompendium„ Abbildung 3, Abbildung 4 und Abbildung 5 vorgestellten Architekturmodells abgedeckt. In der Systemarchitektur werden exemplarisch die Domänen

1. Speicher, 2. Netzwerk, 3. Server und 4. Monitoring

in jeweils 5 Potentialstufen betrachtet. In der Organisationsarchitektur werden exemplarisch die Bereiche

1. IT-Operation und 2. Infrastruktur,

2.1. Brandschutz, 2.2. Energieversorgung, 2.3. Gebäudesicherheit, 2.4. Klimatisierung, 2.5. Zutrittskontrolle

betrachtet. Letzteres mit Sub-Domänen in jeweils 5 Potentialstufen.

Bundesamt für Sicherheit in der Informationstechnik 21

Page 22: Hochverf¼gbare Referenz-Architekturmodelle

3 Übersicht über den Architekturkatalog

Systemarchitektur

Verfügbarkeits-klasse (VK)

1 2 3 4 5

Domäne

Speicher

Wird durch BSI eingefügt, siehe Kommentar V1.01_psf

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Netzwerk Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Server Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Monitoring Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Tabelle 1: Übersicht über Anteile der Systemarchitektur des Architekturkataloges

Organisationsarchitektur

Potentialstufe 1 2 3 4 5

Domäne

IT-Operation Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Infrastruktur-Energieversor-gung

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Infrastruktur-Klimatisierung

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Infrastruktur-Zutrittskon-trolle

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Infrastruktur-Brandschutz

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Infrastruktur-Gebäudesicher-heit

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Wird durch BSI eingefügt

Tabelle 2: Übersicht über Anteile der Organisationsarchitektur des Architekturkataloges

22 Bundesamt für Sicherheit in der Informationstechnik

Page 23: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

4 Notation und NomenklaturIm vorliegenden Kapitel wird eine Struktur zur Beschreibung von Referenz-Architekturen eingeführt. Die Beschreibung einer Architektur beinhaltet dies folgenden vier Bereiche:

a) Allgemeine Informationen zur Architektur: siehe Tabelle 3. Die Detaillierung der dort verwendeten Architekturattribute ist in Tabelle 4 zusammengefasst.

b) ArchitekturskizzeZur Beschreibung einer Systemarchitektur (technische Säule) wird auf die Visualisierung mittels Netzdiagramm, Abbildung 7, zurückgegriffen. Zur Beschreibung einer Organisationsarchitektur wird eine Schichtendarstellung eingesetzt, Abbildung 8.

c) Reliability Block Diagramme (RBD) werden im Falle einer Systemarchitektur (technische Säule) eingesetzt, siehe Abbildung 6.

d) Architekturbeschreibung, siehe Kapitel 4.5Architekturprinzipien zum Design und zur Bewertung von HV-Architekturen werden in Tabelle 5 zusammengefasst und detailliert.

4.1 Allgemeine Architekturinformationen

Allgemeine Architekturinformationen werden in der folgenden Formularvorlage erfasst.

Bundesamt für Sicherheit in der Informationstechnik 23

Page 24: Hochverf¼gbare Referenz-Architekturmodelle

Architekturname: Architektur-Nr.:

HV-Schicht:

Domäne:

Subdomäne:

Referenz: Notation:

Gefährdungen: Standortausstattung:

Schnittstelle: Potential:

Generische Topologie(n):Schutzbedarf nach BSI-Grundschutz:

HV-Prinzip(ien):

Komponente(n):

Architekturmanagement:

Maßnahmen:

Tabelle 3: Formularvorlage für die Beschreibung von HV Architekturmodellen

Komponenten Applikationen Infrastruktur

IT Dienste Personal und Organisation

IT Organisation und Personal

Speichertechnologien

Server

Datenbanken

IT Dienste

Infrastruktur

Monitoring

Reliability Block DiagramBoxes and Lines

regionale Fehler

lokale Fehler globale Fehler

____________________Warm Site

Cold Site Hot Site

Redundanz

Separation

Transparenz

AutomatismenZuverlässigkeit

Service-Autonomie

Lose Kopplung

Wiederverwendbarkeit

Funktionsabstraktion

Orchestrierung von Services

Auffindbarkeit von Services

Vorratsdatenfreiheit des Services (Statelessness)

standard. Service-Schnittstellen Systemarchitektur

Netzwerk

Virtualisierung Priorisierung

Robustheit Fehlertoleranz Skalierbarkeit

Page 25: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

4.1.1 ArchitekturattributeDie Detaillierung der in Tabelle 3 verwendeten Architekturattribute findet sich in der folgenden Auflistung: (vgl. [HV-Kompendium])

Nomenklatur Beschreibung

Architekturname Hier wird die jeweilige Referenzarchitektur benannt.

Architekturnummer Die Architekturnummer setzt sich aus der jeweiligen adressierten Kapitelnummer des HV-Kompendiums sowie der beschriebenen Potentialstufe zusammen. Beispiel: Die Architekturnummer 3-4 verweist demzufolge auf eine Netzwerkarchitektur der Potentialstufe 4.

HV-Schicht Die vorgestellten HV-Referenz-Architekturen werden in den Schichten des HV-Kompendiums (vgl. [HV-Kompendium], Band G, Kapitel 1) verortet:

• Komponenten• IT-Dienste• Applikationen• Personal und Organisation• Infrastruktur

Domäne In Domänen werden fachliche Bereiche mit abgrenzbarer Funktionalität zusammengefasst, z.B.

• IT-Organisation und Personal,• Netzwerk,• Server,• Speichertechnologien,• Datenbanken,• Monitoring und• Infrastruktur.

Diese Domänen entsprechen ausgesuchten Kapiteln des HV-Kompendium, Band B.

Subdomäne Eine Subdomäne, wie beispielsweise Verkabelung (Komponenten), beschreibt einen Teilaspekt der Domäne Netzwerk.

Referenz Hier wird auf das entsprechende Modul des HV-Kompendiums oder auf weitere Standards (z.B. IT-Grundschutz) und Referenz-Prozess-Modelle (z.B. ITIL) verwiesen.

Notation Notationen beschreiben die Art der Darstellung der Architekturskizze (Boxes and Lines, Reliability Block Diagram (RBD) und Business Process Modelling Notation (BPMN)).

Gefährdungen In diesem Feld wird der räumliche Einfluss einer Gefährdung auf das entsprechende Architekturmodell notiert.

a) lokale FehlerLokale Fehler beschränken sich auf Fehler, welche in dem gleichen Raum, in dem gleichen Gebäude oder sonstigen eng benachbarten Gebäuden oder Gebäudeteilen auftreten.

b) regionale FehlerRegionale Fehler beziehen sich auf Fehler, welche in der

25

Page 26: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

Nomenklatur Beschreibung

gleichen Stadt bzw. Ballungsraum oder in einem räumlichen Abstand von < 100km auftreten.

c) globale FehlerGlobale Fehler beziehen sich auf Fehler, welche innerhalb der territorialen Ausdehnung eines Staates oder international in einem Abstand von üblicherweise > 100km auftreten.

Standortausstattung Hier werden die spezifischen Gegebenheiten des Standortes, welche den Anforderungen an einen sicheren Betrieb genügen, angegeben.

a) Cold SiteMit dem Begriff “Cold Site” wird ein Standort bezeichnet, der keine weiteren Ressourcen für die Gewährleistung eines hochverfügbaren Betriebs enthält.

b) Warm SiteDer Begriff “Warm Site” bezeichnet einen Standort, der einige Ressourcen für die Gewährleistung eines hochverfügbaren Betriebs enthält. Im Gegensatz zu „Cold Site“ können die wesentlichen und kritischen Geschäftsprozesse innerhalb relativ kurzer Zeit wieder zur Verfügung gestellt werden.

c) Hot SiteBei einer „Hot Site“ wird ein Server-Standort komplett dupliziert und entspricht in seiner Ausstattung praktisch vollständig dem des primären Standortes und enthält dabei alle Ressourcen für die Gewährleistung eines hochverfügbaren Betriebs. Der konzeptionelle Grundgedanke bei der Einrichtung einer Hot Site ist das Vorhandensein eines alternativen Standortes mit der entsprechenden Infrastruktur, die im Notfall oder Katastrophenfall den Geschäftsbetrieb innerhalb kürzester Zeit übernehmen kann. Durch die vollständig eingerichtete und betriebsbereite „Hot Site“ kann sichergestellt werden, dass die Geschäftsunterbrechung so kurz wie möglich ausfällt.

Schnittstellen In diesem Feld werden weitere Komponenten (Software, Hardware und Infrastruktur) sowie Bereiche (Domäne, Geschäftsprozesse, etc.) fixiert, welche durch das Architekturmodell zusätzlich adressiert werden. Beispielsweise:

• Schnittstellen zu weiteren Architekturen zum Zweck der Orchestrierung,

• Architekturinterne Schnittstellen (z.B. redundante Funktionsstränge) zur Identifikation von Architektureigenschaften, usw.

Generische Topologien An dieser Stelle wird die jeweilige Bezeichnung der Topologie eingetragen (z. B. Bus-, Stern- oder Ring-Topologie) sofern relevant.

Potential In diesem Feld wird das Architekturmodell einer Potentialstufe zugeordnet, wobei die folgend beschriebenen generischen Abstufungen als Orientierungshilfe dienen. Vgl. hierzu die spezifische Ausdifferenzierung für die Organisationsarchitektur in Kapitel „5

Bundesamt für Sicherheit in der Informationstechnik 27

Page 27: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

Nomenklatur Beschreibung

Methodik zur Entwicklung und Bewertung von Architekturen Anhandeines Beispiels„

Potentialstufe 1: Bedarf informell bekannt, Basisanspruch im Bereich Hochverfügbarkeit.

Potentialstufe 2: Bedarf erhoben und sporadisch mit Potential abgeglichen. Erste Prinzipien zur Erreichung der HV, wie Fehlertoleranz, Skalierbarkeit und Transparenz werden umgesetzt.

Potentialstufe 3: Potential erhoben und Bedarf dokumentiert sowie vereinbart. Zusätzliche weiterführende Prinzipien zur Erreichung der HV, so dass lediglich kurze Unterbrechungszeiten, die in einem festgelegten zeitlichen Rahmen auftreten dürfen. Hierbei kommen zusätzliche Prinzipien, wie Separation und Priorisierung zum Tragen.

Potentialstufe 4: Potential analysiert und nach einem Standard bewertet. Bedarf als Anforderungen differenziert und nach Utility und Warranty bewertet. Die Verfügbarkeit muss ununterbrochen aufrecht erhalten werden. Hierzu tragen weitere Prinzipien, wie Virtualisierung, Transparenz, Skalierbarkeit, die aufbauend auf die Stufe 3 Verwendung finden, Rechnung.

Potentialstufe 5: Potential- und Nachfrageanalyse als kontinuierlicher Prozess zur Steuerung von Core Services und Service Level Packages. Die Funktion muss ununterbrochen aufrechterhalten werden. Dies kann zusätzlich zur Stufe 4 durch Automatismen und dem Prinzip der uneingeschränkten Zuverlässigkeit erreicht werden.

Komponenten In dem Feld „Komponenten“ werden die einzelnen Software-, Hardware-, Infrastruktur-, Personal und Organisations-Elemente des Architekturmodells notiert.

HV-Prinzipien Dieses Feld dient der Zuordnung von Prinzipien der Hochverfügbarkeit (vgl. Tabelle 5) auf die Referenzarchitektur.

Architekturmanagement In diesem Feld werden die folgenden Aspekte im Zusammenhang mit dem Architekturmanagement erfasst [BSI_SOA]:

a) Standardisierte Service-SchnittstellenEine der fundamentalen Forderungen ist die nach standardisierten Schnittstellen und Beschreibungen. Beschrieben werden muss, wie der Service genutzt werden kann, welche Daten-(Typen) benötigt werden und wie bestimmte Richtlinien verwendet werden können.

b) Lose Kopplung

28 Bundesamt für Sicherheit in der Informationstechnik

Page 28: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

Nomenklatur Beschreibung

Services sollen lose gekoppelt zu einem Prozess zusammengefügt werden können. Dies setzt ein Minimum an Abhängigkeiten zwischen einzelnen Services voraus. Es gilt der Grundsatz, gerade soviel Abhängigkeiten zu schaffen, dass eine Interoperabilität (auch Austauschbarkeit) noch gewährleistet ist.

c) FunktionsabstraktionUm eine lose Kopplung zu ermöglichen, sollen Services nach außen von Details der konkreten Funktionalität und Implementierung abstrahieren. Lediglich die nach außen angebotenen und beschriebenen Funktionen werden gekapselt angeboten.

d) WiederverwendbarkeitEin Grundgedanke ist die Wiederverwendbarkeit von Services in einem späteren Prozessschritt, von anderen Teilnehmern oder für weitere Verwendungszwecke. Diese Forderung muss bereits bei der Entwicklung Berücksichtigung finden.

e) Service-AutonomieEin Service soll in der Lage sein, autark zu funktionieren. Wenn ein Service alle benötigte Logik, Ressourcen und Umgebung selbst verwaltet bzw. von externen Services unabhängig ist, spricht man von Service-Autonomie.

f) Vorratsdatenfreiheit des Services (Statelessness)Services folgen dem Dienstleistungsgedanken, dass eine definierte Leistung erbracht wird. Diese kann auch die Vorratsdatenspeicherung beinhalten, allerdings nur, wenn explizit verlangt. Sonstige Services halten keine persistenten Daten und müssen dadurch zwischen zwei Serviceaufrufen keine Statusverwaltung durchführen.

g) Auffindbarkeit des ServicesUm einen Service zu nutzen, muss dieser auffindbar sein. In der Regel erfolgt dies über Service-Repositories. Ein Repository steht allen Konsumenten und Providern zur Verfügung und beinhaltet Beschreibungen von Serviceschnittstellen und -implementierungen. Es speichert alle Informationen, welche ein Nutzer benötigt, um einen Service aufzurufen.

h) Orchestrierbarkeit der ServicesOrchestrierung wird das Vorgehen genannt, einzelne Teilarchitekturen aus fachlichen Gesichtspunkten heraus zu höherwertigen IT-Services zu verbinden.

Maßnahmen In diesem Feld werden die Referenzmaßnahmen aus dem Maßnahmenkatalog des HV-Kompendiums aufgeführt. Weitere Maßnahmen bzw. Bausteine, die für das jeweilige Architekturmodell von Bedeutung sind, werden aus den Bereichen Grundschutz (GS), generische Referenz-Prozess-Modelle (CobiT 4.1), etc., mit eingebunden.Die Maßnahmen bestehen aus einer Kurzbezeichnung sowie der

Bundesamt für Sicherheit in der Informationstechnik 29

Page 29: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

Nomenklatur Beschreibung

Beschreibung der Maßnahme bzw. des zugrunde liegenden Verfahrens, wobei auf die Notation des HV-Maßnahmenkatalogs zurückgegriffen wird. Eine ausführliche Beschreibung ist im referenzierten Modul des HV-Kompendiums oder in anderen (de facto) Standardwerken enthalten. Die jeweilige Referenzierung befindet sich in der Spalte „Referenz“.

Tabelle 4: Merkmale von HV-Referenz-Architekturen

4.1.2 Design Prinzipien für HV-ArchitekturenDie Architekturprinzipien zum Design und zur Bewertung von HV-Architekturen werden in der folgenden Tabelle 5 zusammengefasst und detailliert beschrieben. Weitere Informationen hierzu liefert [HV-Kompendium] Band G sowie [HV-Kompendium] „Prinzipien der Verfügbarkeit“.

HV-Prinzip Beschreibung Umsetzung ab Potentialstufe

Redundanz Unter Redundanz wird allgemein das mehrfache Vorhandensein von gleichartigen Objekten verstanden. Dies können technische Komponenten, Informationen, Daten oder auch IT-Personal sein.

1

Robustheit Die Robustheit ist die Eigenschaft eines Systems, seine operationale Verfügbarkeit auch bei einem Betrieb in einem Bereich außerhalb seiner eigentlichen Spezifikation zu gewährleisten. Im Unterschied zur Fehlertoleranz geht es hier daher nicht – oder zumindest nicht ausschließlich – um Fehler innerhalb des Systems, sondern um eine widrige Einwirkung der Umwelt (inklusive der Eingaben) auf das System.[ASA2]

1

Fehlertoleranz Die Fehlertoleranz ist die Eigenschaft eines Systems, trotz des fehlerhaften Verhaltens von Systemkomponenten, wie z. B. deren Ausfall, die operationale Verfügbarkeit zu gewährleisten (maskierende Fehlertoleranz) bzw. wiederherzustellen (nicht-maskierende Fehlertoleranz), d. h. die spezifizierte Funktion zu erbringen.[ASA2]

2

Transparenz Der Begriff Transparenz hat in der IT unterschiedliche Bedeutungen. In Bezug auf IT-Ressourcen bedeutet Transparenz, dass man auf die Ressource zugreifen kann, ohne sie und den Ort ihrer Implementierung zu erkennen. Bezieht man Transparenz auf die IT-Organisation, so wird dadurch ein weiteres Design-Prinzip für HV-Umgebungen bestimmt. In diesem Kontext wird unter Transparenz eher die Durchschaubarkeit oder Deutlichkeit von organisatorischen Zusammenhängen verstanden. (vgl. Fehlertoleranz und Virtualisierung). [HV-Kompendium] „Prinzipien der Verfügbarkeit“

2

Skalierbarkeit Der Begriff „Skalierbarkeit“ beschreibt im Allgemeinen die Anpassungsfähigkeit eines Objektes, eines Systems oder eines

2

30 Bundesamt für Sicherheit in der Informationstechnik

Page 30: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

HV-Prinzip Beschreibung Umsetzung ab Potentialstufe

Verfahrens. Gut skalierbare IT-Infrastrukturen sind in der Lage, flexibel, effizient, schnell und zuverlässig auf wachsende Lasten und Anforderungen zu reagieren.

Separation Separation ist ein weiteres Prinzip zur Realisierung hoher Verfügbarkeit. Im hier betrachteten Kontext beschreibt es die bedarfsgerechte Trennung von Prozessen oder Ressourcen. Dies bedeutet, dass Prozesse mit unterschiedlich hohen Verfügbarkeitsanforderungen auf getrennten Systemen aufgesetzt werden sollten.

3

Virtualisierung Virtualisierung bezeichnet die Auflösung der statischen Beziehung zwischen den Ressourcen, die eine IT-Umgebung zur Verfügung stellt und den Prozessen die diese Ressourcen nutzen. Damit ist es möglich, Anwendungen auf nahezu beliebigen Umgebungen und unter flexibler Nutzung der zur Verfügung stehenden Ressourcen laufen zu lassen.

3

Priorisierung Priorisierung bezeichnet die Konzentration auf unternehmenskritische Prozesse bzw. deren unterstützenden Ressourcen und stellt damit ein Mittel zur bedarfsgerechten Zuordnung der benötigten HV-Umgebung dar.

3

Automatismen Der Begriff „Automatismen“ stammt aus der Verhaltensbiologie und bezeichnet Aktionen von Organismen, die unbeeinflusst vom eigenen Willen automatisiert ablaufen.Im technischen Umfeld sind Automatismen definiert als Abläufe, die sich einer bewussten Kontrolle weitgehend ent-ziehen. [Gratuiertenkolleg Automatismen]

4

Zuverlässigkeit Die Zuverlässigkeit ist die Fähigkeit eines Systems, seinen Dienst über einen gegebenen Zeitraum hinweg zu erbringen. Dies erfordert Eigenschaften, wie technische Sicherheit und Robustheit der Komponenten, Robustheit von Prozessen, Fehlertoleranz. Die Zuverlässigkeit R(t), engl. reliablitiy, einer Betrachtungseinheit ist die Wahrscheinlichkeit, dass die Betrachtungseinheit im Intervall [0,t] alle zugesicherten Eigenschaften bei den beschriebenen Umgebungsbedingungen einhält. [HV-Kompendium] „Definitionen und Metriken für die Hochverfügbarkeit“

5

Tabelle 5: HV-Architekturprinzipien und deren Zuordnung zu Potentialstufen

4.2 Zuverlässigkeits-Blockdiagramme (RBD – Reliability Block Diagram)

Ein Zuverlässigkeits-Blockdiagramm (Reliability Block Diagram - RBD) stellt eine Notation zur

Bundesamt für Sicherheit in der Informationstechnik 31

Page 31: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

Modellierung eines IT-Services durch seine technischen Komponenten oder Sub-Services dar. In einem RBD wird die logische Struktur des betrachteten IT-Services abgebildet, konkret alle Komponenten sowie deren logische Verschaltung untereinander. Jede Komponente oder Sub-Service wird als Block gekennzeichnet. Ein Block kann mit einem weiteren Block verbunden sein, dies wird durch eine Linie gekennzeichnet. Jeder Block kann als Schalter verstanden werden, der ein Signal passieren lässt sobald der Schalter geschlossen ist. Ist der Schalter offen oder defekt kann kein Signal passieren. Ein RBD hat einen (1) Start- und einen (1) Endpunkt, alternativ einen Eingang und einen Ausgang. Das Modell des zu betrachtenden IT-Services gilt als funktionsfähig wenn es einen geschlossenen Pfad vom Eingang bis zum Ausgang aufweist. Jeder Block ist mit einer Ausfallwahrscheinlichkeit versehen. Durch die Auswertung des Modells kann die Verfügbarkeit des modellierten IT-Services (vgl. Abbildung 3, technischer Anteil) bestimmt werden. Die für die Berechnung eines RBD geltenden Grundregeln sind im HV-Kompendium ([HV-Kompendium] Band G) dokumentiert. Durch die Kapselung von Sub-Funktionalität, können hierarchische Modelle entwickelt werden, welche die Orientierung auf einem zielführenden Abstraktionsgrad erleichtert.Zur Definition eines RBD muss die technische Definition des zu modellierenden IT-Services bekannt sein. Diese beinhaltet:

1. Konstituierende Komponenten oder Sub-Services

• Welche Komponenten oder Sub-Services werden benötigt um einen bestimmten IT-Service zur Verfügung zu stellen, z. B.: Software, Hardware, Infrastruktur

2. Logikwissen

• Wie sind diese Komponenten oder Sub-Services verschaltet, seriell, parallel oder vermascht, existieren Ausfallregeln, z.B. 3 von 5 Komponenten müssen funktionsfähig sein, damit der Gesamt-Service seiner Spezifikation nach funktionsfähig ist.

4.3 Architekturskizze für die Techniksäule (Netzdiagramm)

Das Netzdiagramm stellt die physischen Verbindungen von Komponenten dar. Für die Erstellung eines Zuverlässigkeits-Block-Diagramms, RBD (vgl. Kapitel 4.2), ist ein Netzdiagramm nicht zwingend notwendig, unterstützt jedoch die Modellerstellung. Abbildung 7 und Abbildung 6 stellen exemplarisch das Modell einer Speicherarchitektur dar. Abbildung 7 in Form eines Netzdiagramms, Abbildung 6 in Form eines RBD.

32 Bundesamt für Sicherheit in der Informationstechnik

Abbildung 6: Exemplarische RBD Darstellung einer Speicherarchitektur

Page 32: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

In Abbildung 6 wird der Aspekt verdeutlicht, dass im RBD genau eine (1) logische Ausprägung des Netzdiagramms aus Abbildung 7 darstellt wird. Die Verschaltungslogik von Disk 1 und Disk 2, parallel oder seriell, kann aus der Architekturskizze nicht eindeutig abgelesen werden. Zur Berechnung (Quantifizierung) der Verfügbarkeit und der Identifikation von Single Points of Failures (SPoF) ist diese Informationen jedoch zwingend. Obwohl das Netzdiagramm in der Praxis häufiger anzutreffen ist, liefert erst das RBD die zur Steuerung und Quantifizierung der gewünschten Architektur notwendigen Daten.

4.4 Architekturskizze für die Organisationssäule (Organisationsarchitektur)

In der Organisationsarchitektur werden exemplarisch die Informationsebenen 1. Kundenanforderungen (I1)2. IT Dienstleistungen (I2)3. Standard-orientierte Organisationsarchitektur (I3)4. Gewachsene Organisationsarchitektur (I4)5. IT Service Base (I5)

differenziert, siehe hierzu die Erfassungsvorlage in Abbildung 8.

Bundesamt für Sicherheit in der Informationstechnik 33

Abbildung 7: Exemplarisches Netzdiagramm einer Speicherarchitektur

Page 33: Hochverf¼gbare Referenz-Architekturmodelle

Abbildung 8: Exemplarische Vorlage zur Erfassung einer Organisationsarchitektur

Gewachsene Organisationsarchitektur (I4)

Standard -orientierte Organisationsarchitektur (I3)

Kundenanforderungen für verlässlichen und nachhaltigen IT -Betrieb (I1)

Service Base (I5)

Kundenanforderung 1 Kundenanforderung 2 Kundenanforderung 3 Kundenanforderung ... Kundenanforderung n

IT-Dienstleistungen (I2)

Administrator Weiteres Personal / Rollen

ITIL v3 - Prozesslandschaft

Service Design Continual Service ImprovementService Transition

Services des IT-Grundschutzes

Service Operation

IT-Operation Energieversorgung ...

Continual Service Improvement

Page 34: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

4.4.1 Kundenanforderungen (I 1)Kundenanforderungen lassen sich aus strategischen, taktischen oder operativen Vorgaben ableiten. Die systematische Erhebung von Kundenanforderungen für einen verlässlichen und nachhaltigen IT-Betrieb erfolgt hier exemplarisch vor dem Hintergrund „Hochverfügbarkeit“. Beispiele für Kundenanforderungen sind:

• Neuzugänge auslösen und deren Integration steuern (Hard- und Software)• Patch-Management• Warnmeldungen handhaben (Hard- und Software)• Hard- und Software Events handhaben • Security Events managen• Nutzeranfragen abarbeiten

Eine Kundeanforderung aus der behördlichen Praxis ist „Sicherstellung des Geschäftsbetriebes“, welche sich auf Verfügbarkeit abbildet. 4.4.2 IT-Dienstleistung (I 2)IT-Dienstleistungen unterstützen Geschäftsprozesse unmittelbar oder ermöglichen diese erst. Kundeanforderungen werden durch eine oder mehrere IT-Dienstleistungen unterstützt. Eine IT-Dienstleistung ist z.B. Lieferung elektrischer Energie, vgl. [BSI Service-Modell]. Weitere Beispiele für IT-Dienstleistungen sind:

• Klimatisierung• Kommunikation • Kollaboration• Authentifikation

4.4.3 Standard-orientierte Organisationsarchitektur (I 3)Eine Standard-orientierte Organisationsarchitektur unterstützt IT-Dienstleistungen durch eine Prozesslandschaft, die sich idealerweise an einem oder mehreren generischen Referenz-Prozess-Modellen (Standards) orientiert. Beispiele hierfür sind:

• ITIL V3• CobiT 4.1 • BSI IT-Grundschutz

Der Einsatz weiterer oder anderer Standards ist je nach Anforderungslage sinnvoll. Im Rahmen der vorliegenden Studie werden thematisch zusammenhängende Prozessgebiete in Prozesskategorien, wie beispielsweise „Service Operation“, gebündelt (vgl. Abbildung 10).

Prozessgebiete und Prozesskategorien werden wie folgt dargestellt.

35

Page 35: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

Prozessgebiete stellen eine Zusammenfassung von Anforderungen zu einem Thema zur Verfügung, wie beispielsweise „Incident Management“ (vgl. ITIL v3 [ITILv3]) basierend auf Best-Practices. Mehrere thematisch zusammenhängende Prozessgebiete werden in Prozesskategorien, wie beispielsweise „Service Operation“ (vgl. ITIL v3 [ITILv3]), gebündelt.

Weder Prozessgebiete noch Prozesskategorien werden in der Praxis vollständig und nach Lehrbuch implementiert. Typischerweise werden die für die Zielsetzung einer Organisation passenden Prozessanteile mit variierender Güte implementiert. Nicht implementierte Prozessgebiete werden als leere, fragmentarisch implementierte Prozessgebiete durch gestrichelte Prozesspfeile dargestellt (vgl. Abbildung 10).

Bundesamt für Sicherheit in der Informationstechnik 37

Abbildung 9: Darstellung von Prozesskategorien mit enthaltenen Prozessgebieten

Page 36: Hochverf¼gbare Referenz-Architekturmodelle

4 Notation und Nomenklatur

4.4.4 Gewachsene Organisationsarchitektur (I 4)In der Praxis wird man häufig eine gewachsene Prozesslandschaft vorfinden, die den Bedarfen der Organisation angepasst ist, sich aber nicht zwingend an einem Standard orientiert. Hier sind die in der Praxis implementierten Prozessgebiete zu erfassen. Beispiele hierfür sind:

• IT-Administration• Support Handling• Wartung• System Monitoring

4.4.5 Service Base (I 5)Die in der Service Base definierten IT-Ressourcen bilden die Basis für die Unterstützung der Organisationsarchitektur. IT-Ressourcen setzen sich zusammen aus Software, Hardware, Infrastruktur und Personal (SHIP). Im Kontext von Organisationsarchitekturen wird vor allem Personal / Rollen wie z.B. Administratoren, betrachtet.

4.5 Architekturbeschreibung

Die Architekturbeschreibung dient der Zusammenfassung in Prosa aller Architekturbestandteile (vgl. Tabelle 3, Kapitel 4.1 bis Kapitel 4.4 ) sowie einer abschließenden Bewertung der Nutzbarkeit. Ziel der Architekturbeschreibung ist die Darstellung der Funktion sowie das Aufzeigen von Sicherheitsmerkmalen entwickelter Referenzarchitekturen. Eine Architekturbeschreibung untergliedert sich in folgende Abschnitte:

(a) Anforderungen an die Architektur• Anforderungen an die Architektur aus der Schutzbedarfsbetrachtung.

(b) Merkmale der Architektur• Allgemeine Beschreibung des Ist-Zustandes mit direkten Bezug zu der

Architekturskizze.(c) Unterstützung der HV-Prinzipien durch Architekturmerkmale

• Über die allgemeinen Aussagen der umgesetzten HV-Prinzipen (vgl. Tabelle 3) wird hier die Realisierung der Prinzipien durch konkrete Maßnahmen und technische Verfahren innerhalb der Architektur beschrieben. Die Beschreibung organisatorischer Architekturen erfolgt mit Hilfe der generischen Attribute der jeweiligen Potenzialstufen (vgl. Kapitel 4.1). Die spezifischen Merkmale der vorliegenden

38 Bundesamt für Sicherheit in der Informationstechnik

Abbildung 10: Exemplarische Prozesskategorie „Service Operation“ nach ITIL V3.

Page 37: Hochverf¼gbare Referenz-Architekturmodelle

Notation und Nomenklatur

Architektur werden detailliert adressiert und bewertbare Kriterien hervorgehoben.(d) Checkliste zur Feststellung der aktuellen Potentialstufe

• Eine Checkliste unterstützt bei der Ermittlung der aktuellen Potentialstufe. (e) Optimierungspotential für die nächst höhere Potentialstufe sowie Maßnahmen

• Das Optimierungspotenzial beschreibt, basierend auf den Defiziten, das gezielte Erreichen der nächst höheren Potentialstufe, konkretisiert durch die anschließende Maßnahmenzusammenstellung. Die Maßnahmenzusammenstellung ist für die Erreichung der nächst höheren Potentialstufe relevant. Diese Zusammenstellung erhebt keinen Anspruch auf Vollständigkeit. Die aktuellen Maßnahmen sind den jeweiligen Standardwerken zu entnehmen.

(f) Zusammenfassung• Die Zusammenfassung enthält die Darstellung der Vorteile und Nachteile der

Referenzarchitektur hinsichtlich Nutzbarkeit sowie prägende Merkmale der vorliegenden Architektur.

(g) Fazit• Abschließendes kurzes Fazit der Referenzarchitektur in prosa.

Bundesamt für Sicherheit in der Informationstechnik 39

Page 38: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.1 Grundlagen der Methode

Die hier beschriebene Vorgehensweise setzt die Kenntnis der Anforderungen aus der Unternehmensstrategie und Geschäftsprozessen voraus, sowie die daraus erwachsenden Anforderungen an die IT, z.B. technische und fachliche Anforderungen der Fachanwendungen, welche die Geschäftsprozesse unterstützen.

Die Vorgehensweise hierfür wird z.B. im Dokument [BMI - IT Dienste] detailliert beschrieben und liefert als Ergebnis sowohl

• die Anforderungsspezifikation als auch • das Dienstemodell und • den Dienstekatalog mit • den Dienststeckbriefen.

Das Vorgehen nach [CobiTv4.1] liefert vergleichbare Ergebnisse. Ergänzend kann auch das Vorgehen nach [Migrationsleitfaden] herangezogen werden, welches für die Feinplanung noch weitergehende Vorgaben gibt.

Das Vorgehen wird in der folgenden Prozessdarstellung zusammengefasst.

Abbildung 11: Schematisches Vorgehen zur Definition von IT-Zielen für das Ableiten einer IT-Architektur

Die folgenden Kapitel konzentrieren sich auf den Prozess-Schritt „Ableitung einer IT Architektur“. Die Detaillierung und Prozess-Fortsetzung aus Abbildung 11 findet sich in Abbildung 12.

Bei den vorliegenden Referenzarchitekturen liegt der Fokus auf Anforderungen, die sich aus der Schutzbedarfsanalyse nach dem BSI Grundschutz ergeben. In der Praxis werden Anforderungen aus weiteren Bereichen Berücksichtigung finden, wie Eingangs beschrieben z.B. aus der Unternehmensstrategie und Geschäftsprozessen.

5.2 Zielsetzung und Abgrenzung

Vorab wird darauf hingewiesen, dass die im folgenden vorgeschlagenen Vorgehensweise keine pauschale oder generische Architektur erzeugt. Jede Organisation wird ausgehend von individuellen Bedarfen eine für die jeweilige Situation angemessene Architektur entwickeln. Weiterhin wird die

40 Bundesamt für Sicherheit in der Informationstechnik

Definition von IT Zielen und Vorgaben für die IT Architektur

Unternehmensstrategie Anforderungen an Geschäftsprozesse Anforderungen an die IT Ableiten einer IT

Architektur

Page 39: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

einmal entwickelte Architektur nicht statisch bleiben, sondern unterliegt, genau wie das Anforderungsprofil, einer Dynamik, die bei der Weiterentwicklung berücksichtigt werden sollte. Die Praxis zeigt, dass bei vermeintlich gleichen oder ähnlichen Ausgangsbedingungen sehr unterschiedliche Anforderungen und damit Architekturen zum tragen kommen können.

In der Praxis werden die genannten Ziele ergänzt durch eigene Bedarfe oder möglicherweise konkurrierende Ziele. Dies ist bei der Anwendung der vorgestellten Vorgehensweise zu berücksichtigen. Die im folgenden vorgestellte Methodik wurde zur Ableitung der Referenzarchitekturen eingesetzt und durch Erfahrungswerte des BSI ergänzt.

5.3 Die Methodik in Schritten

Die zu Grunde gelegte Vorgehensweise orientiert sich am Drei-Phasen-Modell des HV-Kompendiums, vgl. [HV-Kompendium] Band 1. Vgl. Abbildung 12.

Im Schritt (1 ) werden die Anforderungen an die Architektur erfasst. Beispielsweise sind Anwendungen oder Geschäftsprozesse der Schutzbedarfskategorie „höchstverfügbar“ zuzuordnen, wenn die Auswirkungen im Schadensfall kritisch sein können. Aus der Zuordnung zu einer Schutzbedarfskategorie leitet sich die Potentialstufe sowie daraus resultierende Merkmale der Architektur ab. Das Ergebnis dieses Schrittes beinhaltet einen Anforderungskatalog und/oder eine Grobspezifikation.

In der Praxis werden häufig bereits etablierte IT Landschaften weiterentwickelt. Im Schritt (2) erfolgt daher die Feststellung der aktuellen Ist-Potentialstufe. Die Organisationsarchitektur sowie die Systemarchitektur werden strukturiert erfasst. Das Ergebnis dieser Erfassung ist eine Dokumentation des Ist-Zustandes Anhand einer Prozess-, Komponenten- und Applikationslandschaft. Für die Systemarchitektur werden zusätzlich Abhängigkeiten zwischen Komponenten, zwischen Komponenten und höherwertigen Diensten und zwischen höherwertigen Diensten und Fachanwendungen abgebildet. Als Ergebnis liegt die Dokumentation der Ist-Architektur vor.

Im Schritt (3) werden die Anforderungen aus Schritt (1) und die Ergebnisse aus Schritt (2) gegenübergestellt. Als Ergebnis werden Prozessgebiete identifiziert, die von der Zielstellung abweichen. Das Ergebnis beschreibt die Differenz zwischen Soll und Ist und liefert so das Optimierungspotential.

Im Schritt (4) werden Maßnahmen abgeleitet, die bei der Reduzierung der Lücke zwischen Soll und Ist unterstützen sollen. Diese Maßnahmen speisen sich aus Quellen, die für die Zielsetzung Relevanz besitzen. Für die Zielsetzung „Verfügbarkeit“ bieten sich z.B. die Quellen [BSI IT-Grundschutz], [HV-Kompendium], [CobiTv4.1] und [VAIR] an. Entsprechend der Bedarfe und Ressourcen bietet es sich an, eigene Maßnahmen in den Optimierungs- und Steuerungsprozess aufzunehmen. Auf der planerischen Ebene greifen hier Orchestrierungs-Mechanismen, mit deren Hilfe Teilarchitekturen aus fachlichen Gesichtspunkten heraus zu höherwertigen IT-Services verbunden werden können. Vgl. hierzu Kapitel 5.5 „Orchestrierung„.

Bundesamt für Sicherheit in der Informationstechnik 41

Page 40: Hochverf¼gbare Referenz-Architekturmodelle

Abbildung 12: Schema zur Ableitung einer Architektur

(2) Feststellung der

aktuellen Potentialstufe

(1) Anforderungen

an die Architektur

Ergebnis: Anforderungs-

katalog

(3) Delta

Feststellung

Ergebnis: Dokumentation

der Ist-Architektur

Ergebnis: Optimierungs-potential für die nächst höhere Potentialstufe

(4) Maßnahmen zur Erreichung der nächst höheren Potentialstufe

Ergebnis:Maßnahmenliste

Projektzyklus nach HV-Kompendium

Phase SErmittlung der

Qualitätsanforderungen

Phase MDelta Feststellung, Modellierung , Restrisiko

Phase IIT-Ressourcen (Applikationen )Ermittlung der Service-Delivery

Page 41: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

43

Es kommt die folgende Definition von Anforderungen, Verfügbarkeitsklassen, Potentialstufen und Merkmalen zum Einsatz:

Schutzbedarf Potential-stufe

Beschreibung Merkmal 1 Merkmal 2 V-Klasse (VK)

Tier-Klasse

Gering 1 Keine zugesicherte Verfügbarkeit: Keine besonderen Anforderung an die Verfügbarkeit.

Robuste Komponenten

Robustheit ist Voraussetzung für Skalierbarkeit

VK 0<99%

Normal 2 Normale Verfügbarkeit: Standardsicherheit nach IT-Grundschutz

Partielle Redundanz; einpfadig

SPoFs vorhanden VK 199 %

T 1

Hoch 3 Erhöhte Verfügbarkeit: IT-Grundschutz sowie empfohlene Bausteine für hohen Verfügbarkeitsbedarf, ergänzt durch Risikoanalyse und HV-Maßnahmen

n + 1 Redundanz; zweipfadig bei IT-Verkabelung

Systematische Überwachung zur Identifikation und Beseitigung von SPoFs

VK 299,9%

T2

Sehr hoch 4 Hochverfügbarkeit: Empfehlungen des IT-Grundschutzes für Objekte mit sehr hoher Verfügbarkeit , Hochverfügbarkeits-anforderungen ergänzt durch HV-Maßnahmen

Vollredundanz mit 2 * n, zweipfadig bei Energie-versorgung sowie getrennte Brandabschnitte/Georedundanz

Systematisches Management auf der Basis von Indikatoren, Optimierung nach 2*(n+1)

VK 399,99%

T 3

Höchst-verfügbar

5 Höchstverfügbarkeit: Höchstverfügbares Design auf der Basis HV-Kompendium

Vollredundanz,Mehrpfadigkeit, jeder Pfad n+1 also 2* (n + 1) sowie Georedundanz/Wartungs-redundanz

Systematische Steuerung und Optimierung nach allen technischen und organisatorischen Gesichtspunkten

VK 499,999%

T 4

Desaster Tolerant

5 plus Verfügbarkeit unter extremen Bedingungen: Höchstverfügbares Design auf der Basis HV-Kompendium

Vollredundanz, Mehrpfadig, jeder Pfad n+1 also m* (n + 1)

VK5

Tabelle 6: Methodentabelle zu Anforderungen, Verfügbarkeitsklassen, Potentialstufen und Merkmalen

Page 42: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4 HV Referenzarchitekturen Formularvorlage

In Tabelle 7 wird exemplarisch die ausgefüllte Formularvorlage für die Architektur „Netzwerk Potentialstufe 2 “ angezeigt. Zur Erläuterung der einzelnen Attribute dienst die unter Kapitel 4.1.1 Architekturattribute aufgeführte Tabelle 4 „Merkmale von HV-Referenz-Architekturen „.

5.4.1 Beschreibungshinweise

In den folgenden Abschnitten wird exemplarisch für die System-Architektur

Netzwerk Potentialstufe 2

ein Vorgehen dargestellt, welches bei der Entwicklung und Bewertung eigener Architekturen unterstützen kann. Die Strukturierung der Architekturbeschreibung wurde im Kapitel „4.5 Architekturbeschreibung„ eingeführt. Anmerkungen zur Vorgehensweise werden wie folgt dargestellt:

Bundesamt für Sicherheit in der Informationstechnik 45

Anmerkung:

Beispielanmerkung

Page 43: Hochverf¼gbare Referenz-Architekturmodelle

Architekturname: Netzwerk_Potentialstufe_2 Architektur-Nr.: 3-2

HV-Schicht:

Domäne:

Subdomäne: Komponenten, Leitungsführung, Protokolle, Architektur

Referenz: HV Kompendium, Band B, Kapitel 3 – Netzwerk Notation:

Gefährdungen: Standortausstattung:

Schnittstelle: Potential: 2 VK 1

Generische Topologie(n):Schutzbedarf nach BSI-Grundschutz:

HV-Prinzip(ien):

Komponente(n): Client, Switches (neu), Core-Switch, Service-Switch, Router, Server, Firewall

Architekturmanagement:

Maßnahmen:VM.3.3, VM.3.4, VM.3.10, VM.3.14, VM.3.16, VM.3.19, VM.3.20, VM.3.21, VM.3.22, VM.3.25, VM.3.26, VM.3.27, B 4.2, B 4.5, B 4.6,DS 5.7, DS 12.1, DS 12.3, DS 12.5

Tabelle 7: Exemplarisch ausgefüllte Formularvorlage für die Beschreibung des HV Architekturmodells Netzwerk Potentialstufe 2

Komponenten Applikationen Infrastruktur

IT Dienste Personal und Organisation

IT Organisation und Personal

Speichertechnologien

Server

Datenbanken

IT Dienste

Infrastruktur

Monitoring

Reliability Block DiagramBoxes and Lines

regionale Fehler

lokale Fehler globale Fehler

____________________Warm Site

Cold Site Hot Site

Redundanz

Separation

Transparenz

AutomatismenZuverlässigkeit

Service-Autonomie

Lose Kopplung

Wiederverwendbarkeit

Funktionsabstraktion

Orchestrierung von Services

Auffindbarkeit von Services

Vorratsdatenfreiheit des Services (Statelessness)

standard. Service-Schnittstellen Systemarchitektur

Netzwerk

Virtualisierung Priorisierung

Robustheit Fehlertoleranz Skalierbarkeit

Page 44: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.2 Architekturskizze

Siehe hierzu Abbildung 13 „Architekturskizze Netzwerk Potentialstufe 2„.

47

Anmerkung:

Die Architekturskizze beschreibt anhand eines Netzplans die im Beispiel eingesetzten Komponenten. Die für die Erklärung des Beispiels notwendigen Komponenten werden grau hinterlegt. Sofern es der Übersichtlichkeit dient, werden weitere exemplarische Komponenten außerhalb des grauen Rahmens hinterlegt.

Page 45: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Bundesamt für Sicherheit in der Informationstechnik 49

Abbildung 13: Architekturskizze Netzwerk Potentialstufe 2

Page 46: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.3 Reliability Block Diagram (RBD)

50 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Das Reliability Block Diagramm (RBD) beschreibt aus Verfügbarkeitssicht, die Verschaltung der eingesetzten Komponenten. Konkret wird angezeigt, ob es sich um eine parallele oder serielle Verschaltung handelt.

Das Anwendungsbeispiel beschreibt ein mögliches Einsatzszenario, welches zur Potentialstufe und deren Anforderungen passt.

Page 47: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Anwendungsbeispiel: Über ein Bürgerportal kann ein Bürger eine Befreiung von der Kraftfahrzeugsteuer beantragen. Der Sachbearbeiter greift über ein Netzwerk mit „normaler“ Verfügbarkeit auf die auf den Servern gespeicherten Daten zu und bearbeitet diese.

Bundesamt für Sicherheit in der Informationstechnik 51

Abbildung 14: Reliability Block Diagram Netzwerk Potentialstufe 2

Page 48: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.4 Anforderungen an die ArchitekturGeschäftsprozesse oder Anwendungen des vorstehend beschriebenen Anwendungstypus sind der Schutzbedarfskategorie „normal“ zuzuordnen, da die Auswirkungen im Schadensfall begrenzt und überschaubar sind. Um diese „normalen“ Anforderungen an die Verfügbarkeit eines Geschäftsprozesses zu erfüllen, ist eine Netzwerk-Architektur auf der Potentialstufe 2 zu realisieren. Die Anforderungen der Potentialstufe 2 können durch Anwendung des IT-Grundschutzes (BSI-Standard 100-1 und BSI-Standard 100-2) umgesetzt werden. Die beschriebene Netzwerk-Architektur erreicht damit ein Verfügbarkeitspotential, welches der Verfügbarkeitsklasse 1 zuzuordnen ist.

Folgende Module des IT-Grundschutz finden Anwendung: Abkürzung Bezeichnung

BSI-Standard 100-1 Managementsysteme für Informationssicherheit (ISMS)

BSI-Standard 100-2 IT-Grundschutz-Vorgehensweise

Tabelle 8: Angewendete Module des IT-Grundschutzes in Potentialstufe 2

52 Bundesamt für Sicherheit in der Informationstechnik

Page 49: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.5 Merkmale der Architektur

Die Architektur besteht aus einem einfachen, partiell redundanten Netzwerk mit robusten Komponenten, enthält noch einzelne Single-Point-of-Failures (SPoF) und erfüllt normale Anforderungen an die Verfügbarkeit. Die Potentialstufe 2 zeichnet sich durch folgende Merkmale zur Erfüllung der Anforderungen aus:

Technische Merkmale der Architektur

– Einsatz robuster Switches, d.h. neuwertige bzw. gewartete Geräte in neuwertigem Zustand, Geräte mit langjährigen und bewährten Markteinsatz oder integriertem Überspannungsschutz.

– Die Switches sind inhärent redundant ausgelegt, d.h. Netzteil und ggf. Lüfter sind redundant.

– Es sind Wartungsverträge für Switches abgeschlossen.

– Core-Switches werden durch zusätzliche Service-Switches entlastet.

– Reservegeräte für die Switches existieren oder können durch entsprechende Verträge in kürzester Zeit beschafft werden (kurze MTTR).

– Einsatz eines robusten Routers, d.h. neuwertige bzw. gewartete Geräte in neuwertigem Zustand, Geräte mit langjährigen und bewährten Markteinsatz oder integriertem Überspannungsschutz.

– Der Router ist inhärent redundant ausgelegt, z.B. Netzteil und ggf. Lüfter sind redundant.

– Für den Router ist ein Wartungsvertrag abgeschlossen.

– Für den Router ist ein Reservegeräte vorhanden oder kann über Verträge in kürzester Zeit beschafft werden (kurze MTTR).

Bundesamt für Sicherheit in der Informationstechnik 53

Anmerkung:

Nicht jedes Merkmal kann in einem Netzplan oder einem RBD visualisiert werden. Z.B. „Einsatz hochwertiger Kabel“ kann in beiden Darstellungsformen nicht visualisiert werden. Diese Punkte werden im Bereich „HV-Prinzip“ erläutert.

Die Merkmale einer Potentialstufe werden zunächst aus den unten genannten Quellen extrahiert. Die Merkmale werden dann in Tabellen zusammengefasst und exemplarisch als RBD und Netzdiagramm dargestellt. Die Einblendung der Visualisierung erfolgte bereits im Kapitel „Architekturskizze“ und „Reliability Block Diagramm“

Quellen: • [BSI IT-Grundschutz]• [Uptime Institute Tier Classification]

Page 50: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

– Die Client-seitige Anbindung an den Server ist redundant und verläuft über unterschiedliche Wegstrecken.

– Es erfolgt der Einsatz hochwertiger Kabel und/oder Lichtwellenleiter (z. B. CAT-5-6-7).

– Es werden eine Firewall und Proxies eingesetzt, jedoch sind diese nicht redundant.

– Es sind SPOFs sind vorhanden

Tabelle 9: Technische Merkmale der Potentialstufe 2

5.4.6 Unterstützung der HV-Prinzipien durch Architekturmerkmale

Die dargestellte Netzwerkarchitektur unterstützt die folgenden HV-Prinzipien:– Robustheit,– Redundanz,– Transparenz,– Skalierbarkeit,– Fehlertoleranz.

Die Architektur unterstützt die auf der vorliegenden Potentialstufe relevanten HV-Prinzipien wie in der folgenden Tabelle 10 zusammengefasst. Die Ist-Potentialstufe setzt voraus, dass alle Maßnahmen der vorherigen Potentialstufen sowie alle Maßnahmen des IT-Grundschutzes für „normalen“ Schutzbedarf in den für das Zielobjekt „Netze“ relevanten Bausteinen umgesetzt sind. Siehe Tabelle 11 und 12. Des weiteren sind die relevanten Maßnahmen aus CobiT 4.1 zu berücksichtigen, die Indikatoren für die Architektur in der gegebenen Potentialstufe beschreiben. Vgl. Tabelle 13.

54 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Es werden die zur Potentialstufe gehörenden HV-Prinzipien stichpunktartig aufgelistet. Quellen für die Zuordnung der HV-Prinzipien zu den Potentialstufen und deren Reihenfolge sind:

Quellen: • [Uptime Institute Tier Classification]

Anmerkung:

Die unterstützten HV-Prinzipien werden in einer Tabelle aufgegriffen. In dieser Tabelle wird erläutert, durch welches Merkmal jedes HV-Prinzip in der vorliegenden Architektur unterstützt wird.

Page 51: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

HV-Prinzip HV-Prinzip wird unterstützt durch folgendes Merkmal

Robustheit – Einsatz robuster Switches, d.h. neuwertige bzw. gewartete Geräte in neuwertigem Zustand, Geräte mit langjährigen und bewährten Markteinsatz oder integriertem Überspannungsschutz.

– Einsatz eines robusten Router, d.h. neuwertige bzw. gewartete Geräte in neuwertigem Zustand, Geräte mit langjährigen und bewährten Markteinsatz oder integriertem Überspannungsschutz.

– Es erfolgt der Einsatz hochwertiger Kabel und/oder Lichtwellenleiter (z. B. CAT-5-6-7).

Redundanz – Die Switches sind inhärent redundant ausgelegt, d.h. Netzteil und ggf. Lüfter sind redundant.

– Reservegeräte für die Switches existieren oder können durch entsprechende Verträge in kürzester Zeit beschafft werden

– Der Router ist inhärent redundant ausgelegt.– Für den Router ist ein Reservegeräte vorhanden oder kann

über Verträge in kürzester Zeit beschafft werden.– Die Verkabelung ist teilweise redundant und verläuft über

verschiedene Wegstrecken.– Der Core-Switch wird durch zusätzliche Service-Switches

entlastet

Transparenz – keine zusätzlichen Merkmale

Skalierbarkeit – Der Core-Switch wird durch zusätzliche Service-Switches entlastet.

Fehlertoleranz – Die Switches sind inhärent redundant ausgelegt.– Der Router ist inhärent redundant ausgelegt.

prinzipienübergreifend – Für Switches sind Wartungsverträge abgeschlossen.– Für den Router ist ein Wartungsvertrag abgeschlossen.

Tabelle 10: Zuweisung der Merkmale der Potentialstufe 2 zu den HV-Prinzipien

Ergänzend zu den technischen Merkmalen werden die HV-Prinzipien durch die in der folgenden Maßnahmentabelle zusammengefassten Maßnahmen aus dem HV-Kompendium (VM) unterstützt:

Bundesamt für Sicherheit in der Informationstechnik 55

Page 52: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

HV-Prinzip HV-Prinzip wird unterstützt durch folgende Maßnahme

Robustheit – VM.3.1 Einsatz hochwertiger Kabel und Lichtwellenleiter– VM.3.5 Einsatz von Switches für Punkt-zu-Punkt-Verbindung– VM.3.9 Einsatz von Layer-4-Switches– VM.11.29 Leitungsführung

Redundanz – VM.3.7 Einrichtung breitbandiger Uplinks der Switches mittels Trunking

– VM.3.8 Einsatz von SSL-Proxies

Fehlertoleranz – VM.3.5 Einsatz von Switches für Punkt-zu-Punkt-Verbindung– VM.3.9 Einsatz von Layer-4-Switches

Tabelle 11: Zuweisung der Maßnahmen der Potentialstufe 2 zu den HV-Prinzipien

Ergänzend zu den Maßnahmen aus dem HV-Kompendium wird die Ist-Potentialstufe durch die folgenden Bausteine aus dem IT-Grundschutz des BSI unterstützt:

BSI IT-Grundschutz Bausteine

– B 1.9 Hard- und Software-Management

– B 2.2 Elektrotechnische Verkabelung

– B 2.4 Serverraum

– B 2.9 Rechenzentrum

– B 2.11 Besprechungs-, Veranstaltungs- und Schulungsräume

Tabelle 12: Umzusetzende Bausteine aus dem BSI-Grundschutz

56 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Maßnahmen des BSI IT-Grundschutzes, die notwendig sind um die aktuell vorliegende Potentialstufe zu erreichen werden in einer Tabelle zusammengefasst. Aufgrund des Umfangs wird nicht direkt auf die Maßnahmentabellen des BSI IT-Grundschutzes referenziert, sondern auf die jeweils relevanten Bausteine und damit auf die dort verankerten BSI IT-Grundschutz Maßnahmen, die zu berücksichtigen sind.

Quellen: • [BSI IT-Grundschutz]

Page 53: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Ergänzend zu den Maßnahmen aus dem HV-Kompendium und dem IT-Grundschutz des BSI wird die Ist-Potentialstufe durch die folgenden Maßnahmen aus CobiT unterstützt:

Maßnahmen aus CobiT 4.1 Mögliche Indikatoren

– AI2.6 Wesentliche Upgrades bestehender Systeme

– Prozent der Anwendungssoftwareprojekte, für die ein Qualitätssicherungsplan entwickelt und durchgeführt wird

– Prozent der Anwendungssoftwareprojekte, für die ein angemessenes Review und eine Abnahme der Einhaltung von Entwicklungsstandards durchgeführt wird

– Durchschnittlich benötigte Zeit, um Funktionalität zu realisieren, basierend auf Messgrößen wie Function Points oder Lines of Codes

– Durchschnittlich benötigter Programmieraufwand zur Funktionalitätsrealisierung basierend auf Messgrößen wie Function Points oder Lines of Code

– AI2.10 Wartung von Anwendungssoftware

– AI3.1 Beschaffungsplan für technologische Infrastruktur

– Anzahl und Art der Notfalländerungen an Infrastruktur-Komponenten

– Anzahl offener Beschaffungsanfragen– Durchschnittliche Zeit zur Konfiguration

von Infrastruktur-Komponenten

– AI6.1 Standards und Verfahren für Changes

– Prozent der aufgezeichneten und mit automatisierten Tools verfolgten Änderungen

– Prozent der Änderungen, die formalen Änderungenkontrollprozesse befolgen

– Verhältnis der akzeptierten zu abgelehnten Änderungsanfragen

– Anzahl der unterschiedlichen Versionen

– AI6.2 Bewertung von Auswirkungen, Priorisierung und Freigabe

Bundesamt für Sicherheit in der Informationstechnik 57

Anmerkung:

Maßnahmen und Indikator-Beispiele aus CobiT 4.1 werden in einer Tabelle zusammengefasst.

Quellen: • [CobiTv4.1]

Page 54: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Maßnahmen aus CobiT 4.1 Mögliche Indikatoren

jeder Geschäftsanwendungen oder Infrastruktur, die gewartet werden

– Anzahl und Art der Notfalländerungen an Infrastrukturkomponenten

– Anzahl und Art der Patches an den Infrastrukturkomponenten

– DS5.9 Schutz vor, Erkennung und Korrektur von bösartiger Software

– Häufigkeit und Review der Art der Security-Incidents, die überwacht werden sollen

– Anzahl und Art von veralteten Benutzerkonten

– Anzahl der nicht autorisierten IP-Adressen und Ports sowie der Typen des zugewiesenen Netzwerkverkehrs

– Prozent der kompromittierten und widerrufenen kryptografischen Schlüssel

– Anzahl der Zugriffsberechtigungen, die autorisiert, widerrufen, gelöscht oder verändert wurden

Tabelle 13: Maßnahmen aus CobiT 4.1 in Potentialstufe 2

58 Bundesamt für Sicherheit in der Informationstechnik

Page 55: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.7 Checkliste zur Feststellung der aktuellen Potentialstufe

Die folgende Checkliste unterstützt, neben den Merkmalen und Maßnahmen der obigen Tabellen, bei der Ermittlung der aktuellen Potentialstufe:

FragestellungUmsetzung Ja/Nein

Sind die empfohlenen Maßnahmen der Potentialstufe 1 umgesetzt?

Werden robuste Switches eingesetzt?

Sind die Switches inhärent redundant ausgelegt?

Bestehen Wartungsverträge für die Switches?

Existieren Reservegeräte für die Switches oder Verträge zur kurzfristigen Beschaffung?

Wird der Core-Switch durch einen zusätzlichen Service-Switch entlastet?

Steht ein robuster Router zur Verfügung?

Ist der Router inhärent redundant ausgelegt?

Bestehen Wartungsverträge für den Router?

Existieren Reservegeräte für den Router oder Verträge zur kurzfristigen Beschaffung?

Erfolgt der Anschluss über einen einzigen Internet Service Provider?

Werden hochwertige Kabel oder Lichtwellenleiter eingesetzt?

Wird eine Firewall und ein Proxy eingesetzt?

Werden die Maßnahmen des IT-Grundschutzes für „normalen“ Schutzbedarf in den für das Zielobjekt „Netze“ relevanten Bausteinen umgesetzt?

Tabelle 14: Checkliste der Potentialstufe 2

Bundesamt für Sicherheit in der Informationstechnik 59

Anmerkung:

Zur Feststellung der Potentialstufe einer Architektur wird eine Checkliste erstellt. Die Punkte in dieser Liste erfüllen die folgenden Merkmale:

• Stimmen im Kern überein mit den Merkmalen in Tabelle 9: Technische Merkmale der Potentialstufe 2

• Zusätzlich zu der technischen Eingangsbeschreibung in werden hier ggf. auch organisatorische Maßnahmen aufgeführt

• Die Checkliste adressiert einzelne Komponenten der Architektur

Page 56: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.8 Optimierungspotential für die nächst höhere Potentialstufe

Zur Minimierung der Anzahl der Single-Points-of-Failure (SPoF) und damit der Erhöhung der Verfügbarkeit, sollen in Potentialstufe 3 alle wichtigen Komponenten und Verbindungen, die für die Service-Bereitstellung relevant sind, redundant ausgelegt werden. Die nächst höhere Potentialstufe dient der Erfüllung von hohen Verfügbarkeitsanforderungen.

Bei der Erreichung der nächst höheren Potentialstufe unterstützen die folgenden technischen und organisatorischen Maßnahmen aus dem HV-Kompendium, CobiT 4.1 und Bausteine des IT- Grundschutz:Abkürzung Maßnahme/Baustein

HV-Kompendium

VM.3.3 Einsatz von Fibre Channel oder iSCSI

VM.3.4 Einsatz von Fibre Channel-Switches

VM.3.10 Errichtung redundanter Netzanschlüsse

VM.3.14 Erzeugung von Mehrpfadigkeit durch Switch-Redundanz

VM.3.16 Entwicklung eines Hierarchiekonzepts für alternative Kommunikationswege

60 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Das Optimierungspotential der aktuellen Potentialstufe wird anhand von Maßnahmen erläutert und einem Prosatext dargestellt.

Methode: 1. Schritt 1: Zunächst werden die HV-Prinzipien der nächst höheren Potentialstufe

bestimmt. Anhand dieser werden die Maßnahmen aus dem zur Architektur passenden Bereich des HV-Kompendiums (Domäne = z.B. Netzwerk) gewählt.

2. Schritt 2: Sofern die Maßnahmen aus dem HV-Kompendium auf CobiT verweisen, werden daraus weitere Maßnahmen gewonnen.

3. Schritt 3: Der BSI IT-Grundschutz wird gesichtet, Maßnahmen werden aus der Übereinstimmung der vorliegenden Architektur mit den Bereichen: Komponenten, Semantik, HV-Prinzipien gewonnen.

4. Schritt 4: Sofern eine BSI IT-Grundschutz Maßnahme direkt auf ein CobiT Prozessgebiet verweist, wird dieses berücksichtigt, indem die entsprechende CobiT Maßnahme aufgeführt wird.

5. Schritt 5: Gegebenenfalls werden weitere Maßnahmen definiert, die bei der Erreichung der gesetzten Anforderungen unterstützen.

Quellen:• [BSI IT-Grundschutz]• [HV-Kompendium]• Ggf. [CobiTv4.1]

Page 57: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Abkürzung Maßnahme/Baustein

VM.3.19 Verwendung von Spanning-Tree-Protocol (STP)

VM.3.20 Verwendung von RSTP oder MSTP

VM.3.21 Dynamisches Routing mit BGP (äußeres Fail-Over)

VM.3.22 Entwicklung eines Router Cluster

VM.3.25 Errichtung einer Cluster-fahigen Firewall

VM.3.26 Redundanz statischer Schlüssel im Gateway-Cluster

VM.3.27 Einsatz eines DNS Baum-Cluster

IT-Grundschutz

B 4.2 Netz- und Systemmanagement

B 4.5 LAN-Anbindung eines IT-Systems über ISDN

B 4.6 WLANs

CobiT 4.1

DS5.7 Schutz von Sicherheitseinrichtungen

DS12.1 Standortwahl und Layout von Einrichtungen

DS12.3 Physischer Zugang

DS12.5 Management von infrastrukturellen Einrichtungen

Tabelle 15: Optimierungspotential für die nächst höhere Potentialstufe

Bundesamt für Sicherheit in der Informationstechnik 61

Page 58: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.4.9 Zusammenfassung

In dieser einfachen Netzwerkarchitektur werden robuste Switches, in der Abbildung als Switch gekennzeichnet, eingesetzt. Diese Komponenten orientieren sich am Stand der Technik. In der exemplarische dargestellten Architekturskizze werden zwei Switches eingesetzt und ein einziger Server. In der Praxis werden vergleichbare Architekturen mit einer größeren Anzahl von Clients Einsatz finden. Bei einem Ausfall eines Clients hat der Nutzer die Möglichkeit an einen anderen Client zu wechseln. Der dargestellte Server steht exemplarisch für eine Reihe von Servern, die für die gestellten Anforderungen mit unterschiedlichen Services (z.B. Print-, E-Mail-, DB-Service) verschaltet werden. Mögliche, weitere Server können durch die Anbindung an den Service-Switch hinzugefügt werden.Aufgrund der wachsenden Anforderungen an die Netzwerkarchitektur sollte diese bereits in der Potentialstufe 2 gut geplant und ggf. neu implementiert werden. Dies soll im Ergebnis ein Netz gewährleisten, dass bspw. durch neue Verkabelung und erweiterten Trassen gut skaliert. Die Erreichung höherer Potentialstufen lässt sich nur mit skalierbaren Konzepten erreichen. Eine weitere Voraussetzung ist die vorrangige Verwendung qualitativ hochwertiger Netzkomponenten. Diese besitzen bspw. integrierte Redundanzen (z.B. redundante Netzteile) und sind robuster gegenüber Spitzenlasten im Netzverkehr.Das Prinzip der Robustheit sowie der Fehlertoleranz wird in der vorliegenden Architektur mit Hilfe einer partiell redundanten Verkabelung zwischen Switches und Server und mittels Bildung eines Server-Teilnetz realisiert. Die Leitungen sollten dabei möglichst über unterschiedliche Wegstrecken verlegt werden, um die Gefährdung durch physische Unterbrechungen zu minimieren. Zudem können die redundanten Verkabelungen zur Erhöhung der Bandbreite zwischen Server und Switch genutzt werden, solange beide Pfade verfügbar sind. Zur weiteren Erhöhung der Fehlertoleranz können im Bereich der Core-Switches und Server-Switches Layer-4-Switches eingesetzt werden um bspw. eine Lastverteilung zwischen den Servern zu erreichen.Neben dem Einsatz hochwertiger Kabeln sollte zur Förderung der Transparenz, insbesondere in Rechenzentren, der Einsatz einer strukturierten Verkabelung gemäß EN50173-5 zum Einsatz kommen. Dies dient einer besseren Übersichtlichkeit sowie der Minimierung der Anzahl verlegter Kabel und damit zusätzlicher potentieller Fehlerquellen. Durch den Einsatz leistungsstarker Switches können Kollisionen bei der Netzwerkkommunikation vermieden werden, wodurch sich Zuverlässigkeit und Durchsatz der Netzwerke erhöhen. Zudem sollten die Verbindungen innerhalb des Backbones, also zwischen den Switches, mittels Lichtwellenleiter realisiert sein.Der Einsatz von Firewalls und Proxies erhöht die Sicherheit und verringert die Angreifbarkeit des Netzes, womit eventuelle Ausfallzeiten durch Manipulationen der Konfiguration durch Dritte von außen vermieden werden und damit die Verfügbarkeit gesteigert wird.Die Unterstützung dieser Prinzipien stellt die Anpassbarkeit eines Netzwerks hinsichtlich sich ändernder Bedürfnisse sicher.

62 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Ein Prosatext erläutert die in den Maßnahmen beschriebenen Aktionen und welche Nachteile die Maßnahmen adressieren. Hier werden Hintergründe erläutert, die aus den Maßnahmen nicht deutlich hervorgehen sowie Vorteile, Nachteile und ein Fazit zusammengefasst.

Page 59: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Vorteile• Einsatz robuster Switches und Router• Vorhandensein von Reservegeräten oder entsprechenden Wartungsverträgen• Service-Switch trennt die Server vom Core-Switch und entlastet ihn zusätzlich• Sicherheit durch transparente Filterung mittels Application-Level-Gateways und Firewalls• Ausfälle der Clients und dahinter liegender Switches lassen sich durch einen

Arbeitsplatzwechsel kompensieren

Nachteile• Core- und Service-Switch sowie Firewall und Router stellen Single-Points-of-Failure

(SPoF) dar• Architektur bietet nur geringen Schutz bei Gefährdungen und besitzt daher Defizite im

Bereich Verfügbarkeit, Vertraulichkeit und Integrität

Prägende Merkmale der vorliegenden Architektur: Netze Potentialstufe 2Maßnahmenwirkung Merkmal 1 Merkmal 2

Standardsicherheit nach IT-Grundschutz für normalen Verfügbarkeitsbedarf

Partielle Redundanz Elementare SPoFs liegen vor

Tabelle 16: Prägende Merkmale der Architektur

Der Einsatz von Instrumenten zur Erfassung von Messgrößen im Netzwerk wird empfohlen, ist jedoch nicht zwingend erforderlich. Messwerte sollten angezeigt werden, die Interpretation und Reaktion in Form von Wartungs- und Instandsetzungsarbeiten erfolgt manuell.Mögliche Messgrößen sind z.B. Paketverzögerung, Abweichungen der Laufzeit, Durchsatz, Paketverluste, Vertauschung der Ankunftsreihenfolge von Datenpaketen.

Bundesamt für Sicherheit in der Informationstechnik 63

Anmerkung:

Prägende Merkmale der Architektur werden nochmals in einer Tabelle zusammengefasst. Vgl. Tabelle 6.

Page 60: Hochverf¼gbare Referenz-Architekturmodelle

5 Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

Überwachung Erkennung Reaktion

Kom

pone

nten

Net

zwer

k

sepa

rate

s N

etz

Abt

astr

ate

Zen

tral

es M

gmt

Anz

eige

n

Erk

enne

n

Frü

herk

enne

n

Dat

a M

inin

g

Insp

ektio

n

Inst

ands

etzu

ng

War

tung

auto

nom

e R

eakt

.

auto

mat

isch

e R

eakt

.

man

uell

e R

eakt

.

- - - - - + - - - - + + - - +

Tabelle 17: Monitoringprozesse der Potentialstufe 2

Tabellen-Legende: - sporadisch, empfohlen, gering; + teilweise, erforderlich, hoch; ++ vollständig, zwingend, sehr hoch

Die Architektur in der vorliegenden Potentialstufe unterstützt die TIER-Klasse 1 nach Uptime Institute im Bereich „Netzwerk“.

64 Bundesamt für Sicherheit in der Informationstechnik

Anmerkung:

Zu jeder Architekturbeschreibung wird ein Fazit in einem kurzem Satz gezogen.

Z.B.: „Einfache Netzwerkarchitektur mit normalen Anforderungen an die Verfügbarkeit.“

Page 61: Hochverf¼gbare Referenz-Architekturmodelle

Methodik zur Entwicklung und Bewertung von Architekturen Anhand eines Beispiels

5.5 Orchestrierung

Orchestrierung wird das Vorgehen genannt, bei dem einzelne Teilarchitekturen aus fachlichen Gesichtspunkten heraus zu höherwertigen IT-Services verbunden werden. Orchestrierung dient dem Zweck Geschäftsprozesse optimal durch IT-Services zu unterstützen. Hierzu werden einzelne IT-Services, Fachverfahren und/oder Anwendungen nach dem Baukastenprinzip kombiniert und rekombiniert, so dass neue höherwertige IT-Services entstehen und dem Nutzer in einer definierten Qualität zur Verfügung stehen. Durch die Orchestrierung können IT-Services so aggregiert, integriert und verschachtelt werden, dass Geschäftsprozesse eine planbare, prüfbare, managebare Unterstützung erfahren.

Die im vorliegenden Dokument zur Verfügung gestellten Architektur-Modelle können als konzeptionelle Grundlage zur konkreten Ausgestaltung von IT-Services in der Praxis herangezogen werden. In der technischen Säule kann über die Kombination und Integration mehrerer Teilarchitekturen ein höherwertiger Service etabliert werden. Zur Gestaltung organisatorischer Abläufe stehen Referenz-Prozessmodelle zur Verfügung. Die Kombination dieser Sichtweisen in einem ganzheitlichen methodischen Ansatz stellt die verlässliche Reproduzierbarkeit und Nachhaltigkeit von qualitativ hochwertigen Services zu einer bedarfsgerechten IT-Dienstleistung sicher. Werden sowohl die Technik- als auch die Organisationssäule zum einen ganzheitlich betrachtet (horizontale Integration) und zum anderen konsequent anhand der Anforderungen der zu unterstützenden Geschäftsprozesse ausgerichtet (vertikale Integration), spricht man von der Orchestrierung von IT-Services. Zur Quantifizierung und somit Steuerung der Orchestrierung werden oft Reifegrade oder Potentialstufen eingesetzt.

Beispiel: Über ein Emissionshandelportal kann online mit Emissionszertifikaten gehandelt werden. Nicht verbrauchte Emissionsrechte können durch registrierte Nutzer zum Verkauf angeboten werden, die dann für andere registrierte Nutzer zum Kauf bereitstehen. Die Rechte werden über Online-Zahlung vom Konto abgebucht bzw. gutgeschrieben. Die Validierung der Berechtigungen erfolgt über qualifizierte digitale Signaturen. Das Anwendungsszenario „Emissions-Zertifikatehandel“ vollumfänglich darzustellen überschreitet die Darstellungsmöglichkeiten hier deutlich. Ein wichtiger Bestandteil des Anwendungsszenarios „Emissions-Zertifikatehandel“ ist jedoch die Fachanwendung „e-Akte“, die im genannten Beispiel eingebettet ist, in das übergeordnete Fachverfahren „Emissions-Zertifikatehandel“. Zur Unterstützung der „e-Akte“ bedarf es technischer und organisatorischer IT-Services in einer abgestimmten Qualität und mit bestimmten Merkmalen. Diese werden bestimmt durch die Anforderungsspezifikation, die durch den Geschäftsprozess vorgegeben ist. Zum Beispiel können die Teil-Architekturen Netzwerk, Speicher, Server auf der technischen Seite sowie IT-Organisation, Zutrittskontrolle auf der organisatorischen Seite in den bedarfsorientierten Potentialstufen kombiniert werden. Selbstverständlich werden in der Praxis deutlich mehr IT-Services kombiniert werden um den gewünschten Geschäftsprozess zu unterstützen. Weitere Details hierzu finden sich im Dokument „HV Referenz-Architekturmodelle Beispiel eAkte“

Bundesamt für Sicherheit in der Informationstechnik 65

Page 62: Hochverf¼gbare Referenz-Architekturmodelle

6 Operative Unterstützung

6 Operative Unterstützung Die in den vorangegangenen Kapiteln vorgestellte Vorgehensweise benötigt und erzeugt eine Fülle von Daten. Diese Daten müssen miteinander in Verbindung gesetzt werden, Abhängigkeiten analysiert werden sowie Berechnungen durchgeführt werden. Der Einsatz eines Werkzeugs ist nicht zwingend erforderlich zur Unterstützung der in diesem Dokument vorgestellten Vorgehensweise. Mit einem handelsüblichen Tabellenkalkulations-Werkzeug können viele Tabellen und Darstellungen nachvollzogen werden. Der Einsatz eines Werkzeugs erleichtert jedoch die Datenerfassung, Analyse und Darstellung erheblich und trägt somit, insbesondere bei der Bestimmung quantifizierbarer Verfügbarkeiten, zur Effizienzsteigerung bei der IT-Steuerung bei.

Exemplarische Anforderungen an ein Werkzeug, die im konkreten an die Bedarfe des Anwenders anzupassen sind, werden im Folgenden zusammengefasst:

Architekturebene Anforderungen

FacharchitekturAbbildung von Wirkzusammenhängen zwischen Komponenten und Geschäftsprozessen

Methodische Integration in das I SAGA 4.0 IT Architekturkonzept

SLA Management

Datenübernahme und Schnittstellen zu Werkzeugen, die Geschäftsprozesse modellieren

SystemarchitekturAbbildung von Wirkzusammenhängen zwischen Komponenten

Abbildung von Wirkzusammenhängen zwischen Komponenten und IT-Services

Berechnung der Verfügbarkeit, z.B. mittels Reliability Block Diagrammen (RBD)

Differenzierte MTTR Betrachtung

MTTF Werte für die eingesetzten Komponenten, z.B. aus einer integrierten Datenbank

Schwachstellenanalyse, z.B. mittels SPoF Analyse

Berücksichtigung von Personaleffekten auf die Verfügbarkeit

Benchmarking gegen Referenz-Architekturmodelle, z.B. BSI Hochverfügbarkeits-Referenzmodelle

Reportgenerierung und Dokumentation

Bibliotheken, z.B. Fehlerratendatenbank

OrganisationsarchitekturQualitätsbewertung von Governance Prozessen auf IT Service Ebene unterstützt

Bibliothek praxiserprobter Referenzmodelle, z.B. COBIT,

66 Bundesamt für Sicherheit in der Informationstechnik

Page 63: Hochverf¼gbare Referenz-Architekturmodelle

Operative Unterstützung

Architekturebene Anforderungen

ITIL, MOF oder CMMI

GAP Analyse und Erstellung von Maßnahmen-Katalogen

Benchmarking gegen Referenz-Architekturmodelle und Reifegradmodelle

Reifegradbestimmung

Reportgenerierung und Dokumentation

Sicherheitsarchitektur BSI Grundschutz konforme Szenario-Analysen

GAP Analyse und Erstellung von Maßnahmen-Katalogen

Reportgenerierung und Dokumentation

Datenübernahme und Schnittstellen, z.B. zur AD (Active Directory) Struktur

Tabelle 18: Exemplarische Anforderungen an eine Werkzeugunterstützung

Bundesamt für Sicherheit in der Informationstechnik 67

Page 64: Hochverf¼gbare Referenz-Architekturmodelle

7 Abkürzungsverzeichnis

7 Abkürzungsverzeichnis

A Availability (Deutsch: Verfügbarkeit)

AM Availability Management

BSI Bundesamt für Sicherheit in der Informationstechnik

BPMN Business Process Modelling Notation

CAM Capacity Management

CobiT Control Objectives for Information and related Technology

DB Datenbank

E-Mail Electronic Mail

HV Hochverfügbarkeit

ISM Information Security Management

IEEE Institute of Electrical and Electronics Engineers

IT Informationstechnologie

ITSCM IT Service Continuity Management

ITIL IT Infrastructure Library

KGI Key Goal Indicator

KPI Key Performance Indicator

RBD Reliability Block Diagram

SCM Service Catalogue Management

SLA Service Level Agreement

SLM Service Level Management

SPoF Single Point of Failure

SM Supplier Management

TOGAF The Open Group Architecture Framework

TMR Triple Modular Redundancy

Tabelle 19: Abkürzungsverzeichnis

68 Bundesamt für Sicherheit in der Informationstechnik

Page 65: Hochverf¼gbare Referenz-Architekturmodelle

Glossar

8 Glossar

Begriff Erklärung

Availability Management Der Prozess, der für die Definition, Analyse, Planung, Messung und Verbesserung sämtlicher Aspekte in Bezug auf die Verfügbarkeit von IT-Services verantwortlich ist. Im Availability Management muss sichergestellt werden, dass die gesamte IT-Infrastruktur, sowie sämtliche Prozesse,Hilfsmittel, Rollen etc. für die vereinbarten Service Level Ziele eine entsprechende Verfügbarkeit ermöglichen. [ITILv3 - Service Design]

Capacity Management Der Prozess, bei dem sichergestellt wird, dass die Kapazität der IT-Services und die IT-Infrastruktur ausreicht, um die vereinbarten Service Level Ziele wirtschaftlich und zeitnah erreichen zu können. Beim Capacity Management werden alle Ressourcen, die für die Erbringung von IT-Services erforderlich sind, sowie Pläne für kurz- mittel- und langfristige Business-Anforderungen berücksichtigt. [ITILv3- Service Design]

CobiT CobiT ist eine organisationsbezogene und management- orientierte Sicherheitsrichtlinie für die IT-Governance. Diese wiederum ist vom IT-Governance Institute definiert und "besteht aus der Führung, den Organisationsstrukturen und Prozessen, die sicherstellen, dass die Informationstechnologie die Unternehmensziele unterstützt."

Entität vgl. Komponenten

HV-Umgebung Die methodische Vorgehensweise in diesem Kompendium zur Gestaltung von Architekturen mit HV Eigenschaften sieht eine Modellierung der IT-Ressourcen vor. Die Modellierung einer HV-Umgebung erfolgt durch die Abbildung der für den Geschäftsprozess notwendigen Ressourcen in einem Schichtenmodell. Damit ist eine HV-Umgebung vergleichbar mit dem Informationsverbund von Grundschutz. In der HV-Umgebung kommt der Abhängigkeit der Ressourcen vom Geschäftsprozesses, untereinander und dem daraus resultierenden Zusammenwirken von Maßnahmen in Maßnahmenbündeln eine besondere Bedeutung zu.

Information Security Management Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Assets, Informationen, Daten und IT-Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT-Service Providers hinausgeht, und berücksichtigt die Verwaltung

Bundesamt für Sicherheit in der Informationstechnik 69

Page 66: Hochverf¼gbare Referenz-Architekturmodelle

8 Glossar

Begriff Erklärung

papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation. [ITILv3 - Service Design]

IT-Service Ein Service, der für einen oder mehrere Kunden von einem IT-Service Provider bereitgestellt wird. Ein IT-Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT-Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden. [ITILv3]

IT-Service Continuity Management Der Prozess, der für die Verwaltung von Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT-Services führen können. Das ITSCM stellt sicher, dass der IT-Service Provider stets ein Mindestmaß an vereinbarten Service Levels bereitstellen kann, indem die Risiken auf ein akzeptables Maß reduziert werden und eine Wiederherstellungsplanung für IT-Services erfolgt. Das ITSCM sollte so konzipiert sein, dass es das Business Continuity Management unterstützt. [ITILv3 - ServiceDesign]

ITIL IT Infrastructure Library (ITIL) ist ein IT-Rahmenwerk der englischen Office of Goverment Commerce in UK (OGC) für das Systemmanagement, das das Verfügbarkeitsmanagement und die Störfallerkennung unterstützt.

Komponenten Ein allgemeiner Begriff für einen Teil eines komplexeren Elements. Beispielsweise ein Computersystem kann eine Komponente eines IT-Service sein, eine Anwendung eine Komponente eines Release Unit. Bei Komponenten, die verwaltet werden müssen, handelt es sich um Configuration Items. [ITILv3]

Modell Eine Darstellung eines Systems, Prozesses, IT-Service, Configuration Item etc., die ein einfacheres Verständnis oder Prognosen zu zukünftigem Verhalten unterstützen soll. [ITILv3]

Nomenklatur Verzeichnis der Fachbegriffe in einem Wissensgebiet

Notation Regelwerk zur Beschreibung eines Fachgebietes

Prozess Ein strukturierter Satz an Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel und Steuerungen für das Management enthalten, die für eine zuverlässige Bereitstellung der Outputs erforderlich sind. Ein Prozess

70 Bundesamt für Sicherheit in der Informationstechnik

Page 67: Hochverf¼gbare Referenz-Architekturmodelle

Glossar

Begriff Erklärung

kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren. [ITILv3]

Service Eine Möglichkeit einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen. [ITILv3]

Service Catalogue Management Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen Live IT-Services, einschließlich der Services, die für das Deployment verfügbar sind. Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an die Kunden ausgehändigt wird. Er unterstützt den Vertrieb und die Bereitstellung von IT-Services. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen. [ITILv3 - Service Design]

Service Level Agreement Eine Vereinbarung zwischen einem IT-Service Provider und einem Kunden. Das SLA beschreibt den jeweiligen IT-Service, dokumentiert Service Level Ziele und legt die Verantwortlichkeiten des IT-Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT-Services oder mehrere Kunden abdecken. [ITILv3 - Service Design]

Service Level Management Der Prozess, der für das Verhandeln von Service Level Agreements sowie deren Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT-Service Management Prozesse, Operational Level Agreements und Underpinning Contracts für die vereinbarten Service Level Ziele angemessen sind. SLM ist für das Monitoring und die Berichterstattung in Bezug auf Service Levels sowie für die regelmäßige Durchführung von Kunden-Reviews zuständig. [ITILv3 - Service Design]

Sub-Service vgl. IT-Service Ein Sub-Service ist ein IT-Service, der Bestandteil eines übergeordneten IT-Services ist. Im RBD kann ein Sub-Service eine Entität eines IT-Services darstellen.

Supplier Management Der Prozess ist verantwortlich dafür sicherzustellen, dass alle Verträge mit Suppliern die Anforderungen des Business unterstützen und alle Supplier ihre vertraglichen Verpflichtungen erfüllen. [ITILv3 - Service Design]

Verfügbarkeit Die Verfügbarkeit A(t), engl. availability, einer Betrachtungseinheit ist die Wahrscheinlichkeit, dass die Betrachtungseinheit alle zugesicherten Eigenschaften bei den beschriebenen Umgebungsbedingungen zum beliebigen

Bundesamt für Sicherheit in der Informationstechnik 71

Page 68: Hochverf¼gbare Referenz-Architekturmodelle

8 Glossar

Begriff Erklärung

Zeitpunkt t einhält oder fehlerfrei funktioniert.

Voter Ein Voter definiert Regeln, welche bestimmen wie viele Blöcke eines Reliability Block Diagram (RBD) funktionsfähig sein müssen, damit dieser Teilpfad funktionsfähig bleibt, z.B. Triple Modular Redundancy (TMR).

SPoF Systemkomponenten oder Systempfade werden als Single Point of Failure (SPoF) bezeichnet, wenn durch ihren Ausfall das Gesamtsystem nicht mehr betriebsbereit ist. Das trifft immer dann zu, wenn eine Komponente eine zentrale Funktion im Gesamtsystem übernimmt und beim Ausfall die Funktionen der anderen Komponenten beeinträchtigt.

Tabelle 20: Glossar

72 Bundesamt für Sicherheit in der Informationstechnik

Page 69: Hochverf¼gbare Referenz-Architekturmodelle

Literaturverzeichnis

9 Literaturverzeichnis[660cASA3]: BSI - Bundesamt für Sicherheit in der Informationstechnik, Förderung der Autonomie

der IT-Systeme durch prozessorientiertes Infrastruktur- und Sicherheitsmanagement; Projekt 660c ASA3, 2009

[ASA2]: H.-U. Heiß, M. Werner, J. Richling, G. Muhl, M. C. Jaeger, Studie zur Modellierung von Autonomie in IT-Architekturen,

[BMI - IT Dienste]: BMI - Bundesministerium des Inneren, Ableitung von Diensten aus Geschaftsprozessen, 2010

[BSI IT-Grundschutz]: BSI Bundesamt für Sicherheit in der Informationstechnik, IT-Grundschutz-Kataloge, 2008

[BSI Service-Modell]: BSI - Bundesamt für Sicherheit in der Informationstechnik, 3-Ebenen-Service-Modell, 2011

[BSI_SOA]: BSI - Bundesamt fur Sicherheit in der Informationstechnik, SOA-Security-Kompendium (Sicherheit in Service-orientierten Architekturen), 2010

[CobiTv4.1]: IT Governance Institute (ITGI), CobiT (Control Objectives for Information and Related Technology), 2009

[Gratuiertenkolleg Automatismen]: Winkler Hartmut (Prof. Dr.), Universität Paderborn, Graduiertenkolleg Automatismen, 2011

[HV-Kompendium]: BSI - Bundesamt für Sicherheit in der Informationstechnik, HV-Kompendium, 2011

[ISO/IEC 42010:2007]: IEEE 1471, Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems, Edition 1, 2007

[ITILv3]: Sharon Taylor, ITIL Lifecycle Suite, 2009[ITILv3 - Service Design]: Vernon Lloyd, Colin Rudd, Sharon Taylor, Service Design; TSO (The

Stationery Office); Published for the Office of Government Commerce (OGC), 2007

[Migrationsleitfaden]: BSI - Bundesamt für Sicherheit in der Informationstechnik, Migrationsleitfaden, 2010

[Rahmenarchitektur]: Rat der IT Beauftragten, Rahmenarchitektur IT-Steuerung Bund, [Uptime Institute Tier Classification]: Uptime Institute Professional Services, Data Center Site

InfrastructureTier Standard: Topology, 2009[VAIR]: BSI - Bundesamt für Sicherheit in der Informationstechnik, Verfügbarkeitsanalyse in

Rechenzentren - VAIR - , 2010

Bundesamt für Sicherheit in der Informationstechnik 73