Baustein B 3.303 Speicherl¶sungen / Cloud Storage

Schicht IT-Systeme B 3.303

IT-Grundschutz-Kataloge: 14. EL Stand 2014 1

B 3.303 Speicherlösungen / Cloud Storage

Beschreibung

Speicherlösungen dienen Institutionen zur Speicherung ihrer digitalen Daten. Das stetige Wachstumdieser Daten und das zunehmende Aufkommen unstrukturierter Daten bedingen den effizienten Einsatzmoderner Speicherlösungen innerhalb einer Institution. Dabei unterliegen die Anforderungen an solcheSpeicherlösungen ebenfalls einem Wandel, der sich beispielsweise an folgenden Aspekten beobachtenlässt:

- Die Daten einer Institution sollen jederzeit, an jedem Ort und für unterschiedliche Anwendungssze-narien verfügbar sein. Dadurch gelten für moderne Speicherlösungen häufig gestiegene Verfügbar-keitsanforderungen.

- Die Veränderung der Arbeitsweise hin zur Arbeit in verteilten Teams bedingt in vielen Institutioneneine wachsende Vielfalt von Anwendungen, die Zugriff auf Daten benötigen.

- Die zunehmende Digitalisierung sämtlicher Informationen in einer Institution macht es notwendig,dass weitreichende rechtliche Vorgaben (Compliance-Anforderungen) beachtet und eingehaltenwerden.

- Speicherlösungen sollen dynamisch an die sich stetig ändernden Anforderungen anpassbar seinund Speicherplatz zentral bereitstellen können.

In der Vergangenheit wurden Speicherlösungen oft durch den direkten Anschluss eines Speicherme-diums an einen Server umgesetzt. Diese sogenannten Direct-Attached-Storage (DAS)-Systeme kön-nen die aktuellen und zukünftigen Anforderungen in der Regel jedoch nicht mehr abdecken. Danebenbringen sie häufig stark steigende Kosten durch wachsenden Hardware- und Administrationsbedarf mitsich. Außerdem funktionieren neue Techniken wie die Live-Migration von Daten innerhalb von und überSpeichersysteme hinweg nicht mit DAS. Direct-Attached-Storage-Lösungen können zudem nicht effi-zient verwaltet werden. Der Einsatz zentraler Speicherlösungen wird somit bereits seit Längerem alsnotwendig angesehen und ist in der Praxis weit verbreitet. In diesem Zusammenhang behandelt dieserBaustein:

- Speicherlösungen: Eine Speicherlösung besteht aus einem oder mehreren Speichernetzen sowiemindestens einem Speichersystem.

- Speichernetze: Speichernetze ermöglichen einerseits den Zugriff auf die Speichersysteme, ande-rerseits die Replikation von Daten zwischen Speichersystemen.

- Speichersysteme: Als Speichersystem wird die zentrale Instanz bezeichnet, die für andere SystemeSpeicherplatz zur Verfügung stellt. Der Einsatz eines Speichersystems erlaubt daneben den zeit-gleichen Zugriff mehrerer Systeme (z. B. virtueller und physischer Server, Clients) auf den vorhan-denen Speicherplatz.

Datensicherungsgeräte, die an das Speichersystem oder an das Speichernetz angeschlossen sind, wer-den im Baustein B 1.12 Archivierung betrachtet. Konzeptionelle Aspekte der Datensicherung werden imBaustein B 1.4 Datensicherungskonzept erläutert.

Die Realisierung zentraler Speicherlösungen ist in Abhängigkeit vom Einsatzszenario und den damitverbundenen Anforderungen auf unterschiedliche Art und Weise möglich:

Network Attached Storage (NAS) stellt über die Protokolle NFS (Network File System) und CIFS (Com-mon Internet File System) Zugriffe auf die Speichersysteme zur Verfügung. Der Hauptanwendungsfallbesteht darin, Fileserverdienste zur Verfügung zu stellen. Viele Anbieter verwenden deshalb den Begriff"Filer" für solche Systeme.

Für NAS-Systeme ist daher auch zusätzlich der Baustein B 3.101 Allgemeiner Server anzuwenden.

Storage Area Networks (SAN) werden in der Regel durch ein dediziertes Speichernetz zwischen Spei-chersystemen und angeschlossenen Servern oder Endgeräten geschaffen. SANs wurden für die seriel-



le, sehr schnelle und kontinuierliche Übertragung großer Datenmengen konzipiert. Sie basieren heutefür hochverfügbare, hochperformante Installationen auf der Implementierung des Fibre-Channel- oderIP-Protokolls sowie alternativ auf einer entsprechenden Kombination in Form von Fibre Channel overEthernet (FCoE).

Für Speichernetze ist daher auch der Baustein B 4.1 Heterogene Netze anzuwenden.

Neben diesen weitverbreiteten Speichersystemen und Speichernetzen sind weitere Varianten zu be-trachten:

Speichersysteme, die sowohl über NAS als auch SAN Daten zur Verfügung stellen können, werden oftunter der Bezeichnung Hybrid-Storage oder kombiniertes Speichersystem (Unified Storage) geführt.Nach außen kann ein solches Speichersystem sowohl als NAS als auch als SAN betrieben werden.Dieser Mischbetrieb wird dadurch ermöglicht, dass entsprechende Systemkomponenten eingesetzt undentsprechend konfiguriert werden. So kann sich ein Speichersystem sowohl für einige Anwendungenper Ethernet-Anschluss als "Filer" präsentieren und somit Fileservices über CIFS und NFS zur Verfü-gung stellen als auch für andere Server per Fibre Channel, Fibre Channel over Ethernet oder iSCSISpeicherkapazität zugänglich machen.

Für Hybrid-Systeme sind daher auch die Bausteine B 3.101 Allgemeiner Server und B 4.1 HeterogeneNetze anzuwenden.

Objekt-Storage (oftmals auch als Object-based Storage bezeichnet) ermöglicht gegenüber den tradi-tionellen blockbasierten und filebasierten Zugriffsmethoden einen objektbasierten Zugriff auf Daten.

Objektbasierende Speicherlösungen speichern Daten in Verbindung mit den zugehörigen Metadatenauf einem Datenträger in Form von Objekten und nicht in Form von Dateien. Mittels der Vergabe einereindeutigen Objekt-ID (Hash-Wert), die in den Metadaten des Objekts festgehalten wird, kann das Ob-jekt eindeutig identifiziert werden. Der Zugriff auf einen objektbasierenden Speicher erfolgt über eineführende Anwendung. Die Anwendung greift hierbei über eine spezielle Schnittstelle (Application Pro-gramming Interface (API)) und deren mögliche Kommandos oder direkt per IP auf den Objekt-Storagezu. Im Falle eines Zugriffs per API muss die führende Applikation die herstellerspezifische API des Ob-jekt-Storage unterstützen. Objekt-Storage wird vor allem im Bereich Archivierung, Dokumentenmana-gement und beim Ablegen von Objekten in einer Cloud eingesetzt.

Für objektbasierende Speicherlösungen sind daher auch zusätzlich die Bausteine B 3.101 AllgemeinerServer und B 5.24 Web-Services anzuwenden.

Im Zusammenhang mit Weiterentwicklungen im Speicherumfeld etabliert sich zunehmend auch der Be-griff des Cloud Storage. Hierunter sind Speicherlösungen als Basis für Cloud-Services zu verstehen.Die Speicherlösung an sich bleibt dabei weitgehend unverändert, jedoch liegt eine von den klassischenSAN- oder NAS-Architekturen abweichende Art des Zugriffs auf die gespeicherten Daten vor. Dieserwird in der Regel mittels Web-Service-Schnittstelle (via Representional State Transfer REST & SimpleObject Access Protocol SOAP) realisiert.

Eine besondere Herausforderung im Zusammenhang mit Cloud-Storage ist die Mandantenfähigkeit derGesamtlösung. Aus Anwendersicht sind daher zusätzlich die Bausteine B 1.17 Cloud-Nutzung undB 5.24 Web-Services zu modellieren. Aus Betreibersicht ist daneben der Baustein B 5.23 Cloud Mana-gement zu beachten.

Gefährdungslage

Für den IT-Grundschutz von Speicherlösungen werden folgende typische Gefährdungen angenommen:

Höhere Gewalt- G 1.2 Ausfall von IT-Systemen- G 1.9 Datenverlust durch starke Magnetfelder

Organisatorische Mängel- G 2.1 Fehlende oder unzureichende Regelungen



- G 2.4 Unzureichende Kontrolle der Sicherheitsmaßnahmen- G 2.5 Fehlende oder unzureichende Wartung- G 2.7 Unerlaubte Ausübung von Rechten- G 2.26 Fehlendes oder unzureichendes Test- und Freigabeverfahren- G 2.27 Fehlende oder unzureichende Dokumentation- G 2.37 Unkontrollierter Aufbau von Kommunikationsverbindungen- G 2.48 Ungeeignete Entsorgung der Datenträger und Dokumente- G 2.54 Vertraulichkeitsverlust durch Restinformationen- G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten- G 2.82 Fehlerhafte Planung des Aufstellungsortes von Speicher- und Archivsystemen- G 2.103 Unzureichende Schulung der Mitarbeiter- G 2.109 Fehlende oder unzureichende Planung der Speicherlösung- G 2.182 Fehlendes oder unzureichendes Betreiberkonzept für Speicherlösungen- G 2.183 Fehlendes oder unzureichendes Zonenkonzept- G 2.184 Fehlendes oder unzureichendes Rechte- und Rollenkonzept in Cloud-Infrastrukturen- G 2.185 Fehlende oder unzureichende Softwarewartung (Maintenance) und fehlendes oder

unzureichendes Patchlevel-Management- G 2.186 Fehlende oder unzureichende Regelungen / keine klare Abgrenzung von

Verantwortlichkeiten bei Speicherlösungen- G 2.187 Fehlendes oder unzureichendes mandantenfähiges Administrationskonzept für

Speicherlösungen

Menschliche Fehlhandlungen- G 3.9 Fehlerhafte Administration von IT-Systemen- G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten- G 3.24 Unbeabsichtigte Datenmanipulation- G 3.38 Konfigurations- und Bedienungsfehler- G 3.79 Fehlerhafte Zuordnung von Ressourcen des SAN

Technisches Versagen- G 4.13 Verlust gespeicherter Daten- G 4.53 Unsichere Default-Einstellungen bei Speicherkomponenten- G 4.95 Ausfall von Komponenten einer Speicherlösung- G 4.96 Fehlfunktion von Komponenten einer Speicherlösung

Vorsätzliche Handlungen- G 5.1 Manipulation oder Zerstörung von Geräten oder Zubehör- G 5.2 Manipulation an Informationen oder Software- G 5.4 Diebstahl- G 5.7 Abhören von Leitungen- G 5.8 Manipulation von Leitungen- G 5.10 Missbrauch von Fernwartungszugängen- G 5.18 Systematisches Ausprobieren von Passwörtern- G 5.20 Missbrauch von Administratorrechten- G 5.28 Verhinderung von Diensten- G 5.57 Netzanalysetools- G 5.89 Hijacking von Netz-Verbindungen- G 5.102 Sabotage- G 5.129 Manipulation von Daten über das Speichersystem- G 5.130 Manipulation der Konfiguration einer Speicherlösung- G 5.185 Erlangung physischen Zugangs auf SAN-Switches- G 5.186 Zugriff auf Informationen anderer Mandanten durch WWN-Spoofing- G 5.187 Überwindung der logischen Netzseparierung- G 5.188 Unberechtigter Zugriff auf Daten innerhalb einer Cloud-Storage-Lösung- G 5.189 Verlust der Vertraulichkeit durch storagebasierte Replikationsmethoden



Maßnahmenempfehlungen

Um einen Inforationsverbund abzusichern, müssen, gemäß den Ergebnissen der Modellierung nach IT-Grundschutz, zusätzlich zu diesem Baustein, noch weitere Bausteine umgesetzt werden.

Um eine Speicherlösung sicher aufbauen sowie betreiben zu können, sind eine Reihe von Maßnahmenumzusetzen. Beginnend mit der strategischen Entscheidung, welche Art von Speicherlösung zu wählenist, folgt deren Konzeption und die Beschaffung der entsprechenden Komponenten. Die Installation undKonfiguration der Speicherlösung führt schließlich zum Übergang in die Betriebsphase, an deren EndeMaßnahmen zur ordnungsgemäßen Aussonderung der Speicherlösung umzusetzen sind.

Parallel zur Betriebsphase muss durch eine geeignete Notfallvorsorgeplanung sichergestellt werden,dass der Betrieb auch im Notfall aufrechterhalten werden kann. Informationssicherheitsmanagementund Revision stellen begleitend die Einhaltung des Regelwerks sicher.

Der schrittweise Aufbau und Betrieb einer Speicherlösung sowie die Maßnahmen, die in den jeweiligenPhasen beachtet werden sollten, sind im Folgenden aufgeführt:

Planung und Konzeption

Nachdem die Anforderungen analysiert worden sind, sollte durch die Verantwortlichen entschieden wer-den, welche Ausprägung der beschriebenen Speicherlösungen idealerweise zukünftig innerhalb der In-stitution einzusetzen ist. Dabei ist in einem ersten Schritt zu klären, welche Technik geeignet erscheint,um die ermittelten Anforderungen angemessen abzudecken (siehe M 2.362 Auswahl einer geeignetenSpeicherlösung und M 2.351 Planung von Speicherlösungen).

Als Ausgangspunkt der Planung ist grundsätzlich die mit zentraler Speicherkapazität zu versorgendeAnwendung zu betrachten. Nur auf diesem Weg lassen sich die Sicherheitsanforderungen an das Spei-chersystem und das Speichernetz und somit an die Speicherlösung in ihrer Gesamtheit sinnvoll definie-ren. Wichtige Parameter bei der Planung sind das über die Betriebszeit zu erwartende Wachstum desSpeicherplatzes, der von der Anwendung benötigt wird, sowie die erforderliche Leistungsfähigkeit unddie Sicherheitsanforderungen. Dabei muss die Auslegung der Speicherkomponenten durch absehbareEntwicklungen und fundierte Wachstumsprognosen so definiert werden, dass diese zentralen IT-Kom-ponenten auf Dauer den Anforderungen der Institution genügen können. Die abgeleiteten Anforderun-gen an die einzusetzende Speicherlösung sollten im Anschluss in einer Sicherheitsrichtlinie festgehaltenwerden (siehe M 2.525 Erstellung einer Sicherheitsrichtlinie für Speicherlösungen).

Ergibt sich aus der Anforderungsanalyse, dass es notwendig ist, eine mandantenfähigen Speicherlö-sung einzusetzen, so ist festzulegen, wie die Trennung der Mandanten umgesetzt werden soll (sieheM 2.528 Planung der sicheren Trennung von Mandanten in Speicherlösungen). Bei höheren Anforde-rungen an die Verfügbarkeit oder die Skalierbarkeit empfiehlt sich der Einsatz einer hochverfügbarenSpeicherlösung (siehe M 2.354 Einsatz einer hochverfügbaren SAN-Lösung). Als weitere umzusetzendeMaßnahmen bei einem erhöhten Schutzbedarf, insbesondere hinsichtlich der Vertraulichkeit und Inte-grität der gespeicherten Daten, empfiehlt sich der Einsatz von Verschlüsselungsmechanismen oder dieEinführung eines Zonenkonzeptes (siehe M 4.448 Einsatz von Verschlüsselung für Speicherlösungenund M 4.449 Einführung eines Zonenkonzeptes).

Neben der reinen Abschätzung und Planung der benötigten Speicherkapazität ist insbesondere frühzei-tig die geeignete Aufstellung der Speicherlösung zu prüfen (siehe M 1.59 Geeignete Aufstellung vonSpeicher- und Archivsystemen). Dabei ist kritisch zu hinterfragen, ob die Serverräume oder das Re-chenzentrum technisch und organisatorisch geeignet sind, um Speicherlösungen dort unterzubringen.Die eigentliche Aufstellung erfolgt im Rahmen der Umsetzungsphase.

Mit der Planung eines Speichersystems muss auch die Planung eines angemessenen Datensicherungs-konzeptes einhergehen. Dazu ist das Datensicherungskonzept (B 1.4 Datensicherungskonzept) der In-stitution organisatorisch und technisch an die Anforderungen anzupassen, die sich aus dem Einsatz dergewählten Speicherlösung ergeben.



Beschaffung

Nachdem die grundsätzliche Definition der Anforderungen an die einzusetzende Speicherlösung abge-schlossen worden ist, sind die Angebote möglicher Hersteller und Lieferanten zu prüfen, und ein geeig-neter Anbieter ist auszuwählen (siehe M 2.355 Auswahl von Lieferanten für eine Speicherlösung).

In der Folge sind, im Rahmen der Vertragsgestaltung mit den gewählten Dienstleistern, Service LevelAgreements (kurz SLAs) zu treffen. Die Ausprägung der SLAs sollte sich in realistischer Weise mit denermittelten Anforderungen der Planungsphase decken (siehe M 2.356 Vertragsgestaltung mit Dienstlei-stern für Speicherlösungen).

Umsetzung

Nachdem die organisatorischen und planerischen Vorarbeiten abgeschlossen sind, kann die Speicher-lösung implementiert werden. Die erfolgreiche Umsetzung der geplanten Speicherlösung erfordert dabeisowohl die Abstimmung der erkennbaren Anforderungen des Betriebs mit den ermittelten Sicherheits-vorgaben als auch die Dokumentation einer Reihe weiterer Regelungen, Anforderungen und Einstellun-gen (siehe M 2.526 Planung des Betriebs der Speicherlösung).

Weiterhin sind aus Sicherheitssicht für die Umsetzungsphase insbesondere die folgenden Maßnahmenzu beachten:

- Es ist eine sichere Grundkonfiguration der Speicherlösung vorzunehmen (siehe M 4.274 SichereGrundkonfiguration von Speichersystemen).

- Die Administration der Speicherlösung sollte möglichst über ein separates, abgesichertes Netz er-folgen (siehe M 2.357 Aufbau eines Administrationsnetzes für Speichersysteme).

- Alle Administratoren müssen auf den Umgang mit der ausgewählten Speicherlösung geschult wer-den (siehe M 3.54 Schulung der Administratoren des Speichersystems).

Der Aufbau einer Speicherlösung bedingt in der Regel die Umsetzung einer logischen Zuordnung zwi-schen Servern und den weiteren Komponenten der Speicherlösung. Diese ist nach den schriftlich spezi-fizierten Anforderungen und Planungen der vorangegangenen Phasen vorzunehmen (siehe M 5.130 Ab-sicherung des SANs durch Segmentierung).

Mit den Erkenntnissen der Testphase ist eine Systemdokumentation anzufertigen, die sowohl die ein-gesetzte Hard- und Software vollumfänglich erfasst als auch alle vorzunehmenden Schritte zur Installa-tion und individuellen Konfiguration der Speicherlösung beschreibt (siehe M 2.358 Dokumentation derSystemeinstellungen von Speichersystemen).

Betrieb

Nach erfolgreicher Erstinstallation und Durchlauf einer Testphase kann der Regelbetrieb aufgenommenwerden. Unter Sicherheitsgesichtspunkten sind dabei folgende Aspekte zu beachten:

- Die bedarfsgerechte Bereitstellung der Funktionalität einer Speicherlösung setzt deren sicheren Be-trieb voraus. Vor diesem Hintergrund müssen unter anderem jene Dienstprogramme abgesichertwerden, die der Unterstützung betrieblicher Funktionen der Speicherlösung dienen und daher um-fangreiche Berechtigungen benötigen (siehe M 4.275 Sicherer Betrieb einer Speicherlösung).

- Während des Regelbetriebs einer Speicherlösung werden Daten erfasst, gespeichert und weiterver-arbeitet. Sofern diese Daten nicht mehr benötigt werden, müssen Maßnahmen ergriffen werden, dieeine sichere Löschung gewährleisten (siehe M 2.527 Sicheres Löschen in SAN-Umgebungen).

- Speicherlösungen müssen im laufenden Betrieb überwacht und gewartet werden (sieheM 2.359 Überwachung und Verwaltung von Speicherlösungen).

- Neben der Überwachung und Wartung, die vor allem die technische Verfügbarkeit sicherstellen soll,müssen weitere sicherheitsrelevante Aspekte kontrolliert werden (siehe M 2.360 Sicherheits-Auditsund Berichtswesen bei Speichersystemen).

- Als zusätzliche Maßnahme bei erhöhtem Schutzbedarf hinsichtlich der Integrität der SAN-Fabricempfiehlt sich der Einsatz von Storage-Protokollen mit erweiterten Sicherheitsmerkmalen (sieheM 4.447 Sicherstellung der Integrität der SAN-Fabric).



Aussonderung

Empfehlungen zur Deinstallation von Einzelkomponenten und von Komplettsystemen, etwa nach Been-digung des Regelbetriebs, finden sich in der Maßnahme M 2.361 Außerbetriebnahme von Speicherlö-sungen.

Notfallvorsorge

Der Einsatz von Speicherlösungen erfordert die Überarbeitung und Anpassung vorhandener IT-Notfall-pläne. Empfehlungen zur Notfallvorsorge finden sich in der Maßnahme M 6.98 Notfallvorsorge und Not-fallreaktion für Speicherlösungen.

Nachfolgend wird das Maßnahmenbündel für diesen Baustein vorgestellt.

Planung und Konzeption- M 2.351 (A) Planung von Speicherlösungen- M 2.354 (Z) Einsatz einer hochverfügbaren SAN-Lösung- M 2.362 (A) Auswahl einer geeigneten Speicherlösung- M 2.525 (A) Erstellung einer Sicherheitsrichtlinie für Speicherlösungen- M 2.528 (Z) Planung der sicheren Trennung von Mandanten in Speicherlösungen- M 2.529 (W) Modellierung von Speicherlösungen- M 3.92 (W) Grundlegende Begriffe beim Einsatz von Speicherlösungen- M 4.448 (Z) Einsatz von Verschlüsselung für Speicherlösungen- M 4.449 (Z) Einführung eines ZonenkonzeptesBeschaffung- M 2.355 (C) Auswahl von Lieferanten für eine Speicherlösung- M 2.356 (C) Vertragsgestaltung mit Dienstleistern für SpeicherlösungenUmsetzung- M 1.59 (A) Geeignete Aufstellung von Speicher- und Archivsystemen- M 2.357 (B) Aufbau eines Administrationsnetzes für Speichersysteme- M 2.358 (A) Dokumentation der Systemeinstellungen von Speichersystemen- M 2.526 (A) Planung des Betriebs der Speicherlösung- M 3.54 (A) Schulung der Administratoren des Speichersystems- M 4.80 (B) Sichere Zugriffsmechanismen bei Fernadministration- M 4.274 (A) Sichere Grundkonfiguration von Speichersystemen- M 5.130 (B) Absicherung des SANs durch SegmentierungBetrieb- M 2.359 (B) Überwachung und Verwaltung von Speicherlösungen- M 2.360 (B) Sicherheits-Audits und Berichtswesen bei Speichersystemen- M 2.527 (B) Sicheres Löschen in SAN-Umgebungen- M 4.275 (A) Sicherer Betrieb einer Speicherlösung- M 4.447 (Z) Sicherstellung der Integrität der SAN-FabricAussonderung- M 2.361 (C) Außerbetriebnahme von SpeicherlösungenNotfallvorsorge- M 6.1 (A) Erstellung einer Übersicht über Verfügbarkeitsanforderungen- M 6.98 (A) Notfallvorsorge und Notfallreaktion für Speicherlösungen

Goldene Regeln

Speicherlösungen dienen Institutionen zur Speicherung ihrer digitalen Daten. Eine Speicherlösung bein-haltet dabei immer mindestens ein Speichernetz, über das unter Zuhilfenahme unterschiedlicher Proto-kolle der Zugriff auf ein oder mehrere Speichersysteme ermöglicht wird. Diese stellen anderen Syste-men (z. B. virtuellen und physischen Servern, Clients, Appliances) zentral vorhandenen Speicherplatzzur Verfügung und gewährleisten den zeitgleichen Zugriff mehrerer Systeme. Die Realisierung zentralerSpeicherlösungen ist in Abhängigkeit vom Einsatzszenario und den damit verbundenen Anforderungen



auf unterschiedliche Art und Weise möglich, beispielsweise als SAN (Storage Area Network), NAS (Net-work Attached Storage) oder als Hybrid-Storage.

- Die sicherheitsrelevanten Regelungen, um Speicherlösungen einzusetzen, müssen in einer Sicher-heitsrichtlinie dokumentiert sein.

- Um zentrale Speicherlösungenen betreiben zu können, sind spezielle Kenntnisse aufseiten der Ad-ministratoren erforderlich. Diese müssen daher sowohl hinsichtlich technischer Entwicklungen alsauch im Zusammenhang mit Sicherheitsaspekten ausreichend geschult sein.

- Um eine angemessene Speicherlösung auszuwählen, sollte vorher eine Anforderungsanalyse erfol-gen. Dazu sind die maßgeblichen Anforderungen an die Verfügbarkeit, Performance und Kapazitätbasierend auf den Anwendungen und der Hardware, die von der Speicherlösung zukünftig unter-stützt werden sollen, zu ermitteln.

- Die detaillierte Planung einer Speicherlösung erfolgt auf der Basis der ermittelten Anforderungen.Sie sollte neben Überlegungen zu geeigneter Hardware, Herstellern und Lieferanten auch eine Ent-scheidung zum Einsatz zentraler Managementsysteme, zur Planung des Netzanschlusses, der In-frastruktur sowie zur Integration in bestehende Prozesse beinhalten.

- Unter Betrachtung einer Reihe von Auswahlkriterien ist ein geeigneter Lieferant für die Speicherlö-sung zu identifizieren. Im Rahmen der Vertragsgestaltung sollten allgemeine Verpflichtungen hin-sichtlich des Einsatzes von organisatorischen und technischen Maßnahmen zur IT-Sicherheit fest-gehalten werden. Darüber hinaus empfiehlt es sich, alle vereinbarten Leistungen messbar und prüf-bar im Vertrag schriftlich zu fixieren.

- Im Vorfeld der Freigabe einer Speicherlösung für den Produktivbetrieb sollte diese sicher konfiguriertwerden. Dazu sind die Default-Einstellungen zunächst in einem gesonderten Testnetz zu überprüfenund anzupassen.

- Die Dokumentation der Konfiguration muss aktuell und vollständig sein, um bei Notfällen schnellreagieren zu können und Fehler bei Änderungen im System zu vermeiden.

- Es sollte ein Änderungsmanagement für den Betrieb von Speicherlösungen etabliert werden, dasVorgaben zu Planung, Test und Freigabe von Änderungen und Aktualisierungen regelt.

- Für den Betrieb von Speicherlösungen müssen in Abhängigkeit von den Revisionsvorgaben Maß-nahmen zur Notfallvorsorge ergriffen werden. Dazu ist ein Notfallplan zu erstellen und es sind Re-gelungen zum Wiederanlauf und zu Tests bzw. Übungen zu treffen.

- Werden Speicherlösungen nicht mehr benötigt, so ist sicherzustellen, dass alle gespeicherten Da-ten in geeigneter Weise auf andere Speicherlösungen übertragen werden. Anschließend sind alleNutzdaten und Konfigurationsdaten sicher zu löschen.

Die Sicherheitsempfehlungen zum Thema Storage müssen zielgruppengerecht aufbereitet und institu-tionsweit veröffentlicht werden. Weitere Informationen zum Thema Speicherlösungen / Cloud Storagefinden sich im Baustein B 3.303 Speicherlösungen / Cloud Storage und in weiteren Bereichen der IT-Grundschutz-Kataloge.

Gefährdungskatalog Höhere Gewalt G 1.2 Bemerkungen


G 1.2 Ausfall von IT-Systemen

Der Ausfall einer Komponente eines IT-Systems kann zu einem Ausfall desgesamten IT-Betriebs und damit dem Ausfall wichtiger Geschäftsprozesseführen. Insbesondere zentrale Komponenten eines IT-Systems sind geeignet,solche Ausfälle herbeizuführen, z. B. LAN-Server, Netzkoppelelemente. Auchder Ausfall von einzelnen Komponenten der technischen Infrastruktur, bei-spielsweise Klima- oder Stromversorgungseinrichtungen, kann zu einem Aus-fall des gesamten Informationsverbunds beitragen.

Ursache für den Ausfall eines IT-Systems ist nicht immer technisches Versa-gen (z. B. G 4.1 Ausfall der Stromversorgung). Ausfälle lassen sich auch oftauf menschliches Fehlverhalten (z. B. G 3.2 Fahrlässige Zerstörung von Gerätoder Daten) oder vorsätzliche Handlungen (z. B. G 5.4 Diebstahl, G 5.102 Sa-botage) zurückführen. Auch mangelnde Wartung, beispielsweise durch Ausfalldes Wartungspersonals, kann zu technischem Versagen führen. Auch durchhöhere Gewalt (z. B. Feuer, Blitzschlag, Chemieunfall) können Schäden ein-treten, allerdings sind diese Schäden meist um ein Vielfaches höher.

Werden auf einem IT-System zeitkritische Anwendungen betrieben, sind dieFolgeschäden nach einem Systemausfall entsprechend hoch, wenn es keineAusweichmöglichkeiten gibt.

Beispiele:- Durch Spannungsspitzen in der Stromversorgung wird das Netzteil eines

wichtigen IT-Systems zerstört. Da es sich um ein älteres Modell handelt,steht nicht unmittelbar ein Ersatz bereit. Die Reparatur nimmt einen Tagin Anspruch, in dieser Zeit ist der gesamte IT-Betrieb nicht verfügbar.

- Es wird eine Firmware in ein IT-System eingespielt, die nicht für diesen Sy-stemtyp vorgesehen ist. Das IT-System startet daraufhin nicht mehr feh-lerfrei und muss vom Hersteller wieder betriebsbereit gemacht werden.

- Bei einem Internet Service Provider (ISP) führte ein Stromversorgungsfeh-ler in einem Speichersystem dazu, dass dieses abgeschaltet wurde. Ob-wohl der eigentliche Fehler schnell behoben werden konnte, ließen sichdie betroffenen IT-Systeme anschließend nicht wieder hochfahren, da In-konsistenzen im Dateisystem auftraten. Bis alle Folgeprobleme behobenwaren, waren mehrere der vom ISP betriebenen Webserver tagelang nichterreichbar.

- In elektronischen Archiven kann der Zeitpunkt der erstmaligen Archivie-rung als Entstehungszeitpunkt von Dokumenten fehlinterpretiert werden,wenn keine anderweitigen Beweisverfahren, z. B. Zeitstempeldienste, zurBeglaubigung eingesetzt werden. Dies gilt vor allem für Geschäftspro-zesse, in denen die elektronische Archivierung von massenhaft anfallen-den Belegdaten transparent eingebunden ist. Im vorliegenden Fall konn-te aufgrund des Ausfalls einer Archivkomponente ein Teil von Belegda-ten erst um einen Tag verzögert archiviert werden. Durch die Verwendungvon WORM-Medien wurde die Reihenfolge der physikalischen Archivie-rung der Geschäftsbelege trotzdem nachweisbar dokumentiert. Es wurdejedoch kein Nachweis für die ansonsten nicht auftretende Verzögerungdurch die ausgefallene Archivkomponente geführt. Dadurch entstand beieiner späteren Prüfung der Eindruck einer nachträglichen Manipulation.

Gefährdungskatalog Höhere Gewalt G 1.9 Bemerkungen

IT-Grundschutz-Kataloge: Stand Juli 1999 9

G 1.9 Datenverlust durch starkeMagnetfelder

Typische Datenträger mit magnetisierbaren Speichermedien sind Disketten,Wechselplatten, Kassetten und Bänder. Informationen werden über Schreib-/Leseköpfe aufgebracht. Die derart magnetisierten Datenträger sind empfind-lich gegenüber magnetischer Störstrahlung, so dass die Nähe zu solchenStrahlungsquellen vermieden werden sollte.

Je nach Stärke der Strahlung führt diese zu mehr oder weniger großen Daten-verlusten. Besonders kritisch ist dies bei Dateien, die aufgrund ihrer internenFormatierung bereits durch geringfügige Veränderungen gänzlich unbrauch-bar werden (z. B. PostScript-Dateien, Datenbanken).

Beispiele für Quellen magnetischer Störstrahlung sind:

- Elektromotoren,- Transformatoren,- Ausweiselesegeräte auf Magnetfeldbasis.

Gefährdungskatalog Organisatorische Mängel G 2.1 Bemerkungen


G 2.1 Fehlende oder unzureichendeRegelungen

Die Bedeutung übergreifender organisatorischer Regelungen und Vorgabenfür das Ziel Informationssicherheit nimmt mit dem Umfang der Informations-verarbeitung, aber auch mit dem Schutzbedarf der zu verarbeitenden Infor-mationen zu.

Von der Frage der Zuständigkeiten angefangen bis hin zur Verteilung von Kon-trollaufgaben kann das Spektrum der Regelungen sehr umfangreich sein. Aus-wirkungen von fehlenden oder unzureichenden Regelungen werden beispiel-haft in den anderen Gefährdungen des Gefährdungskatalogs G2 beschrieben.

Vielfach werden nach Veränderungen technischer, organisatorischer oderpersoneller Art, die wesentlichen Einfluss auf die Informationssicherheit ha-ben, bestehende Regelungen nicht angepasst. Veraltete Regelungen könneneinem störungsfreien Betrieb entgegen stehen. Probleme können auch da-durch entstehen, dass Regelungen unverständlich oder zusammenhanglosformuliert sind und dadurch missverstanden werden.

Dass Regelungsdefizite zu Schäden führen können, machen folgende Bei-spiele deutlich:

- Durch eine mangelhafte Betriebsmittelverwaltung kann der termingerech-te Arbeitsablauf in einem Rechenzentrum schon durch eine unterbliebeneDruckerpapierbestellung stark beeinträchtigt werden.

- Neben einer Beschaffung von Handfeuerlöschern muss auch deren regel-mäßige Wartung geregelt sein, um sicherzustellen, dass diese im Brand-fall auch funktionstüchtig sind.

- Bei einem Wasserschaden wird festgestellt, dass dieser auch den darunterliegenden Serverraum in Mitleidenschaft zieht. Durch eine unzureichendeSchlüsselverwaltung kann der Wasserschaden im Serverraum allerdingsnicht unmittelbar behoben werden, weil keiner darüber informiert ist, wosich der Schlüssel zum Serverraum gerade befindet. Dadurch steigt derSchaden erheblich.



G 2.4 Unzureichende Kontrolle derSicherheitsmaßnahmen

Werden bereits eingeführte Sicherheitsmaßnahmen (z. B. Klassifizierung vonInformationen, Datensicherung, Zutrittskontrolle, Vorgaben für Verhalten beiNotfällen) nicht konsequent umgesetzt und regelmäßig kontrolliert, kann essein, dass sie nicht wirksam sind oder missachtet werden. Mängel, die beieiner Kontrolle festgestellt werden, lassen sich meist ohne Schaden abstellen.Wenn Verstöße erst anlässlich eines Schadensfalls auffallen, kann oft nichtmehr rechtzeitig und der jeweiligen Situation angemessen reagiert werden.

Darüber hinaus gibt es Sicherheitsmaßnahmen, die nur wirksam sind, wennVerantwortliche sie kontrollieren. Hierzu zählen beispielsweise Protokollie-rungsfunktionen, deren Sicherheitseigenschaften erst zum Tragen kommen,wenn die Protokolldaten ausgewertet werden.

Beispiele:- Zur Vorbereitung von Straftaten kommt es vor, dass Schließzylinder in Au-

ßentüren und Toren von nicht autorisierten Personen ausgetauscht wer-den. Gerade wenn es sich um Zugänge handelt, die selten genutzt werdenoder lediglich als Notausgänge vorgesehen sind, werden diese bei Strei-fengängen nur in Panikrichtung geprüft. Die Funktionalität der Schließ-zylinder wird dabei oft vernachlässigt. Zur Vorbereitung von Straftatenkommt es vor, dass Schließzylinder in Außentüren und Toren von nichtautorisierten Personen ausgetauscht werden. Gerade wenn es sich umZugänge handelt, die selten genutzt werden oder lediglich als Notausgän-ge vorgesehen sind, werden diese bei Streifengängen nur in Panikrichtunggeprüft. Die Funktionalität der Schließzylinder wird dabei oft vernachläs-sigt.

- Die Sicherheitsleitlinie einer Institution schreibt vor, dass die eingesetztenSmartphones nicht "gerootet" werden dürfen bzw. dass kein "Jailbreak"durchgeführt werden darf, da so die Sicherheitseigenschaften des Betrie-bssystems umgangen werden können. Solche modifizierten Smartphonessind innerhalb einer Institution nicht mehr sicher einsetzbar. Wird dieseVorgabe nicht überprüft, ist es möglich, dass Mitarbeiter mit einem unsi-cheren Smartphone auf das Netz oder schützenswerte Informationen derInstitution zugreifen.

- In einer Behörde werden einige Unix-Server zur externen Datenkommu-nikation eingesetzt. Aufgrund der zentralen Bedeutung dieser IT-Syste-me sieht das Sicherheitskonzept vor, dass die Unix-Server wöchentlicheiner Integritätsprüfung unterworfen werden. Da nicht regelmäßig kontrol-liert wird, ob diese Überprüfungen tatsächlich stattfinden, fällt erst bei derKlärung eines Sicherheitsvorfalls auf, dass die IT-Abteilung auf solche In-tegritätsprüfungen verzichtet hat. Als Grund wurde die mangelhafte per-sonelle Ausstattung der Abteilung genannt.

- In einem Unternehmen wurde die Rolle des z/OS-Security-Auditors nichtbesetzt. Dies hatte zur Folge, dass die Einstellungen im RACF im Laufeder Zeit nicht mehr den Sicherheitsvorgaben des Unternehmens entspra-chen. Erst nach einem Produktionsausfall wurde bemerkt, dass einige An-wender mehr Rechte hatten, als sie für ihre Tätigkeit benötigten. Eine fürdie Produktion wichtige Anwendung war von ihnen versehentlich gestopptworden. In einem Unternehmen wurde die Rolle des z/OS-Security-Audi-tors nicht besetzt. Dies hatte zur Folge, dass die Einstellungen im RACFim Laufe der Zeit nicht mehr den Sicherheitsvorgaben des Unternehmensentsprachen. Erst nach einem Produktionsausfall wurde bemerkt, dass ei-nige Anwender mehr Rechte hatten, als sie für ihre Tätigkeit benötigten.



Eine für die Produktion wichtige Anwendung war von ihnen versehentlichgestoppt worden.



G 2.5 Fehlende oder unzureichendeWartung

Die Funktionsfähigkeit der eingesetzten Technik muss gewährleistet bleiben.Durch regelmäßige Wartung kann die Funktionsfähigkeit der eingesetztenTechnik gefördert werden. Werden Wartungsarbeiten nicht oder nur unzurei-chend durchgeführt, können daraus unabsehbar hohe Schäden oder Folge-schäden entstehen.

Beispiele:- Die Batterien einer unterbrechungsfreien Stromversorgung (USV) verfü-

gen infolge fehlender Wartung über eine unzureichende Kapazität (zu ge-ringer Säuregehalt). Die USV kann einen Stromausfall nicht mehr ausrei-chend lange überbrücken.

- Die Feuerlöscher verfügen aufgrund fehlender Wartung nicht mehr übereinen ausreichenden Druck, so dass ihre brandbekämpfende Wirkungnicht mehr gewährleistet ist.

- Der Laserdrucker fällt aufgrund von Überhitzung aus, weil ein Lüftungsgit-ter nicht vorschriftsmäßig gereinigt wurde.

- Im Serverraum stehen viele Geräte mit eigener Hitzeentwicklung. Kom-men dazu noch hochsommerliche Temperaturen und eine nicht ausrei-chende Klimatisierung (z. B. fehlende oder defekte Klimaanlage) desRaumes, kann es vereinzelt zu temperaturbedingten Geräteausfällen auf-grund von Überhitzung kommen. Klimaanlagen, die fest installiert sind,müssen daher regelmäßig gewartet und gereinigt werden, um eine verläs-sliche und störungsfreie Funktion sicherzustellen.



G 2.7 Unerlaubte Ausübung vonRechten

Rechte wie Zutritts-, Zugangs- und Zugriffsberechtigungen werden als orga-nisatorische Maßnahmen eingesetzt, um Informationen, Geschäftsprozesseund IT-Systeme vor unbefugtem Zugriff zu schützen. Werden solche Rechtean die falsche Person vergeben oder wird ein Recht unautorisiert ausgeübt,können sich eine Vielzahl von Gefahren für die Vertraulichkeit und Integritätvon Daten oder die Verfügbarkeit von Rechnerleistung ergeben.

Beispiele:- Der Arbeitsvorbereiter, der keine Zutrittsberechtigung zum Datenträgerar-

chiv besitzt, entnimmt in Abwesenheit des Archivverwalters Magnetbän-der, um Sicherungskopien einspielen zu können. Durch die unkontrollierteEntnahme wird das Bestandsverzeichnis des Datenträgerarchivs nicht ak-tualisiert, die Bänder sind für diesen Zeitraum nicht auffindbar. Der Arbeits-vorbereiter, der keine Zutrittsberechtigung zum Datenträgerarchiv besitzt,entnimmt in Abwesenheit des Archivverwalters Magnetbänder, um Siche-rungskopien einspielen zu können. Durch die unkontrollierte Entnahmewird das Bestandsverzeichnis des Datenträgerarchivs nicht aktualisiert,die Bänder sind für diesen Zeitraum nicht auffindbar.

- Ein Mitarbeiter ist erkrankt. Ein Zimmerkollege weiß aufgrund von Beob-achtungen, wo dieser sein Passwort auf einem Merkzettel aufbewahrt undverschafft sich Zugang zum Rechner des anderen Mitarbeiters. Da er erstkürzlich durch ein Telefonat mitbekommen hat, dass der Kollege noch ei-ne fachliche Stellungnahme abzugeben hatte, nimmt er hier unberechtig-terweise diese Aufgabe im Namen seines Kollegen wahr, obwohl er zuder Thematik nicht auf dem aktuellen Sachstand ist. Eine daraus folgen-de Erstellung einer Ausschreibungsunterlage in der Verwaltungsabteilungfordert im Pflichtenheft daher eine längst veraltete Hardwarekomponente,weil die dortigen Mitarbeiter der fachlichen Stellungnahme des erfahrenenKollegen uneingeschränkt vertraut haben.



G 2.26 Fehlendes oder unzureichendesTest- und Freigabeverfahren

Wird neue Hard- oder Software nicht oder nur unzureichend getestet und ohneInstallationsvorschriften freigegeben, kann es passieren, dass Fehler in derHard- oder Software nicht erkannt werden oder dass die notwendigerweiseeinzuhaltenden Installationsparameter nicht erkannt bzw. nicht beachtet wer-den. Diese Hardware-, Software- oder Installationsfehler, die aus einem feh-lenden oder unzureichenden Software-Test- und Freigabeverfahren resultie-ren, stellen eine erhebliche Gefährdung für den IT-Betrieb dar.

Im Vertrauen auf eine problemlose Installation neuer Hard- bzw. Software wirdoftmals übersehen, dass mögliche Schäden in keinem Verhältnis zu dem Auf-wand stehen, den ein geordnetes Test- und Freigabeverfahren erfordert. Pro-gramme oder IT-Systeme werden unzureichend getestet und mit Fehlern ineine Produktionsumgebung eingebracht. Die Fehler wirken sich in der Folgestörend auf den bis zu diesem Zeitpunkt problemlosen Betrieb aus.

Beispiele für solche Schäden werden nachfolgend aufgezeigt:

- Programme oder Programm-Updates lassen sich nicht sinnvoll nutzen,da für ein annehmbares Verarbeitungstempo mehr Ressourcen (z. B.Hauptspeicher, Prozessorkapazität) als erwartet benötigt werden. Wirddies nicht im Test erkannt, kann das zu erheblichen Fehl- oder Folgein-vestitionen führen. Nicht selten führten Entscheidungen gegen weitere In-vestitionen dazu, dass IT-Systeme oder Anwendungen zwar gekauft undbezahlt, jedoch nie benutzt wurden.

- Eingeübte Arbeitsabläufe werden nach Installation neuer Software maß-geblich behindert. Der mit der Installation des Programms beabsichtigteNutzen stellt sich erst bedeutend später ein, da die Mitarbeiter im Vorfeldnicht geschult bzw. nicht über die neuen Funktionen des Programms in-formiert wurden.

- Durch das Einspielen eines Updates einer DBMS-Standardsoftware, dasmit Fehlern behaftet ist, steht die Datenbank nicht mehr zur Verfügungoder es kommt zu Datenverlust.

- Einige Software-Produkte installieren den Microsoft SQL Server Express(SSE) als Datenbank, ohne dass dies vom Benutzer bemerkt wird. Hier-bei handelt sich um eine Ausprägung des Microsoft SQL Servers mit dentypischen Gefährdungen eines Datenbanksystems. Oft sind die Benutzerdes Produktes bzw. die Administratoren, die das Produkt installieren, nichtausreichend über diese Gefährdungen informiert und versäumen, sicher-heitsrelevante Maßnahmen zu ergreifen. So wird häufig in Verbindung mitSSE ein Benutzerkonto in der Datenbank für den Administrator angelegt,das in der Grundinstallation über keinen Passwortschutz verfügt. Auf dieseWeise können Angreifer einen Vollzugriff auf die Daten und gegebenen-falls sogar auf das Betriebssystem erhalten.

- In einer Bank wurden die Betriebssysteme zahlreicher Netzkomponentenaktualisiert. Danach blockierte die neue Version eines Paketfilters denKommunikationsport einer selten genutzten, aber enorm wichtigen Funk-tion des kritischen datenbankbasierten Handelssystems. Dies hatte zurFolge, dass die Kunden der Bank nicht mehr auf die Anwendung zugreifenund wichtige Dienste nutzen konnten. Durch Regressforderungen erlitt dieBank einen finanziellen Schaden.



G 2.27 Fehlende oder unzureichendeDokumentation

Verschiedene Formen der Dokumentation können betrachtet werden: die Pro-duktbeschreibung, die Administrator- und Benutzerdokumentation zur Anwen-dung des Produktes und die Systemdokumentation.

Eine fehlende oder unzureichende Dokumentation der eingesetzten IT-Kom-ponenten kann sowohl im Auswahl- und Entscheidungsprozess für ein Pro-dukt, als auch bei einem Schadensfall im Wirkbetrieb erhebliche Auswirkun-gen haben.

Bei einer unzureichenden Dokumentation kann sich im Schadensfall, bei-spielsweise durch den Ausfall von Hardware bzw. Fehlfunktionen von Pro-grammen, die Fehlerdiagnose und -behebung erheblich verzögern oder völligundurchführbar sein.

Dies gilt auch für die Dokumentation von Leitungswegen und Verkabelungeninnerhalb der Gebäude-Infrastruktur. Ist aufgrund unzureichender Dokumen-tation die genaue Lage von Leitungen nicht bekannt, so kann es bei Bauarbei-ten außerhalb oder innerhalb eines Gebäudes zu Beschädigungen von Leitun-gen kommen. Dabei kann es zu längeren Ausfallzeiten (Eintritt eines Notfalls)oder unter Umständen sogar zu lebensbedrohenden Gefahren, zum Beispieldurch Stromschlag, kommen.

Beispiele:- Wenn von einem Programm Arbeitsergebnisse in temporären Dateien zwi-

schengespeichert werden, ohne dass dies ausreichend dokumentiert ist,kann dies dazu führen, dass die temporären Dateien nicht angemessengeschützt und vertrauliche Informationen offengelegt werden. Durch feh-lenden Zugriffsschutz auf diese Dateien oder eine nicht korrekte physika-lische Löschung der nur temporär genutzten Bereiche können Informatio-nen Unbefugten zugänglich werden.

- Bei Installation eines neuen Softwareproduktes werden bestehende Kon-figurationen abgeändert. Andere, bislang fehlerfrei laufende Programme,sind danach falsch parametrisiert und stürzen gegebenenfalls ab. Durcheine detaillierte Dokumentation der Veränderung bei der Installation vonSoftware ließe sich der Fehler schnell lokalisieren und beheben.

- In einer größeren Behörde wurde die Verkabelung der IT durch eine ex-terne Firma vorgenommen. Die Anfertigung einer Dokumentation war imLeistungsumfang nicht enthalten. Da nach Fertigstellung der Verkabelungmit der Firma kein Wartungsvertrag abgeschlossen wurde, verfügte dieBehörde nicht über die notwendige Dokumentation. Erweiterungen desNetzes konnten nur mit erheblichen Verzögerungen vorgenommen wer-den (siehe auch G 2.12 Unzureichende Dokumentation der Verkabelung).

- In einer z/OS-Installation wurden jeden Abend automatisch Batch-Jobs zurVerarbeitung von Anwendungsdaten gestartet. Für die Verarbeitung wares wichtig, dass die Batch-Jobs in der richtigen Reihenfolge abliefen. Alseines Abends die Automation versagte, mussten die Jobs manuell gestar-tet werden. Aufgrund fehlender Dokumentation wurden die Batch-Jobs inder falschen Reihenfolge gestartet. Dies führte zu Abbrüchen in der Ver-arbeitung der Anwendungsdaten und zu Verzögerungen in der Produktionum mehrere Stunden.

- Fehlende Datenblätter von (flüchtigen) Halbleiterspeichern wie SRAM(Static Random Access Memory) und DRAM (Dynamic Random Access



Memory) können dazu führen, dass die Speicher nicht ordnungsgemäßgelöscht und damit vertrauliche Informationen bekannt werden können.

- In einem Unternehmen sollten USB-Sticks (nichtflüchtige Speicher) aus-gemustert werden. Die Produktbeschreibungen waren nicht aufzufinden.Die USB-Sticks wurden daher mit dem vorhandenen Löschtool behandelt.Auf herstellerspezifische Besonderheiten konnte jedoch nicht eingegan-gen werden, so dass nicht alle Daten ordnungsgemäß und sicher gelöschtwurden.


IT-Grundschutz-Kataloge: Stand 2005 18

G 2.37 Unkontrollierter Aufbau vonKommunikationsverbindungen

Beim Einsatz von Kommunikationskarten innerhalb eines IT-Systems (Fax-,Modem- oder ISDN-Karten) ist für den Benutzer nicht immer offensichtlich,was außer seinen Nutz- und Protokollinformationen zusätzlich übertragenwird. Nach Aktivierung einer Kommunikationskarte ist es grundsätzlich mög-lich, dass diese, ohne Initiierung durch den Benutzer, Verbindungen zu einernicht gewünschten Gegenstelle aufbaut oder, über dem Benutzer nicht be-kannte Remote-Funktionalitäten, durch Dritte angesprochen wird.

Beispiele:- Bei der erstmaligen Konfiguration einer Faxkarte wurde der Benutzer vom

Installationsprogramm nach der Landesvorwahl von Schweden gefragt. Zuvermuten ist, dass der Kartenhersteller über den Einsatz seines Produkts,eventuell aus Gründen des Produkt-Marketings, informiert werden wollte.

- Eine große Anzahl von Modem-Karten unterstützt den ferngesteuerten Zu-griff auf IT-Systeme. Zwar lassen sich diese Zugriffe über teilweise sogarauf den Karten integrierte Mechanismen (Callback-Option und Rufnum-mernauthentisierung) absichern, voreingestellt ist dies jedoch nicht. Einso konfiguriertes IT-System lässt sich, über die Modemkarte, von außenvollständig manipulieren.



G 2.48 Ungeeignete Entsorgung derDatenträger und Dokumente

Wenn Datenträger oder Dokumente nicht geeignet entsorgt werden, könnenhieraus unter Umständen Informationen extrahiert werden, die Dritten nicht indie Hände fallen sollten.

Beispiele:- Angreifer müssen nicht immer komplizierte technische Attacken austüf-

teln, um über Schwachstellen in IT-Systemen an Informationen zu gelan-gen. Viel einfacher und erfolgreicher kann die Informationsgewinnung ausder Mülltonne (Dumpster Diving) sein. Büromüll, wie beispielsweise Dis-ketten, CD-ROMs, interne Telefonbücher oder auch die aktuellen Erfolgs-bilanzen, ist im Allgemeinen nicht besonders schmutzig und kann sehrviele interessante und weiterverwertbare Informationen enthalten.

- CD-ROMs können zur Wiederverwertung an vielen Stellen abgegebenwerden. Leider wird hierbei häufig nicht bedacht, dass auch CD-ROMsmit "alten" Datensicherungen oder anderen Dateien für Externe noch in-teressante Informationen enthalten können. Das Zerkratzen der Oberflä-che reicht hier nicht, um Interessierte an der Auswertung von Informatio-nen erfolgreich zu hindern.

Auch alte oder defekte IT-Systeme enthalten häufig eine Vielzahl von span-nenden Informationen. So hat eine Test-Kaufreihe einer Computer-Zeitschriftergeben, dass auf 90 % der gebraucht gekauften Festplatten noch die voll-ständigen Informationen der vorherigen Besitzer enthalten waren.

Beispiele:- Zwei Wissenschaftler vom Massachusetts Institute of Technology haben

untersucht, wie viele sensitive Daten über den Handel mit gebrauchtenComputern und Computerkomponenten in die Hände Unbefugter gelan-gen. Ihre Untersuchung ergab, dass nur 10 % der IT-Komponenten so ge-säubert worden waren, dass keine Daten rekonstruiert werden konnten.Die übrigen Platten enthielten unter anderem Pornographie, Liebesbrie-fe, Kreditkartennummern oder Patientendaten. Der "Hauptgewinn" war ei-ne Festplatte, die zuvor offensichtlich in einem Geldautomaten eingebautwar, und auf der neben Kontonummern und Kontoständen auch ein Teilder verwendeten Software zu finden war.

- Der Käufer eines ausgemusterten Behördencomputers wandte sich anDatenschutzbeauftragte und Presse, nachdem er darauf die nur scheinbargelöschten Daten eines Nachlassgerichtes rekonstruieren konnte.

Sind für Telearbeiter am häuslichen Arbeitsplatz keine geeigneten Möglichkei-ten vorhanden, um Datenträger und Dokumente geeignet zu entsorgen, wan-dern diese erfahrungsgemäß meist in den Hausmüll. Auch dort, wo unterwegsgearbeitet wird, besteht die bedauerliche Neigung, Entwürfe und anderes "Un-nützes" direkt in die nächsten Papierkörbe zu geben oder einfach liegen zulassen, sei es im Hotel oder in der Bahn.

Beispiel:- So wurden bereits aus Patientenakten von den Nachbarskindern Papier-

flugzeuge gebastelt. Diese waren von einem Telearbeiter als Altpapier zurEntsorgung vor die Haustür gestellt worden. Da die brisanten Papierflug-zeuge anschließend überall in der Nachbarschaft zu finden waren, wardies bald als Nachricht über den schlechten Datenschutz einer Klinik inder Lokalpresse zu lesen.



G 2.54 Vertraulichkeitsverlust durchRestinformationen

Bei elektronischer Datenübermittlung oder Datenträgerweitergabe passiert esimmer wieder, dass dabei auch Informationen weitergegeben werden, die dieInstitution nicht verlassen sollten. Als mögliche Ursachen für die unbeabsich-tigte Weitergabe von Informationen lassen sich folgende Beispiele anführen:

- Eine Datei enthält Textpassagen, die als "versteckt" oder "verborgen" for-matiert sind. Solche Textpassagen können Bemerkungen enthalten, dienicht für den Empfänger bestimmt sind.

- Dateien, die mit Standardsoftware wie Textverarbeitungsprogrammenoder Tabellenkalkulationen erstellt worden sind, können Zusatzinformatio-nen über Verzeichnisstrukturen, Versionsstände, Bearbeiter, Kommenta-re, Bearbeitungszeit, letztes Druckdatum, Dokumentnamen und -beschrei-bungen enthalten. Besonders hervorzuheben sind in diesem Zusammen-hang Funktionen, die mehreren Bearbeitern das gemeinsame Bearbeiteneines Dokuments erlauben. Solche Funktionen löschen Textpassagen, dieein Bearbeiter löscht oder überschreibt, nicht wirklich aus dem Dokument,sondern markieren diese nur als gelöscht und erlauben es späteren Bear-beitern, Änderungen ganz oder teilweise rückgängig zu machen. Praktischalle aktuellen Office-Suites (beispielsweise Microsoft Office und OpenOffi-ce) bieten diese Möglichkeit. Werden die Daten solcher Änderungen nichtvor der Weitergabe entfernt, so erhält der Empfänger neben dem tatsäch-lichen Dokument unter Umständen eine große Menge weiterer Informatio-nen.

- Praktisch alle aktuellen Office-Suites besitzen die Möglichkeit der Schnell-speicherung von erstellten Dokumenten. Dies führt dazu, dass nur die Än-derungen an einem Dokument gespeichert werden. Dieser Vorgang nimmtvergleichsweise weniger Zeit in Anspruch als ein vollständiger Speicher-vorgang, bei dem die Office-Suite das vollständige überarbeitete Doku-ment speichert. Ein vollständiger Speichervorgang erfordert weniger Fest-plattenspeicher als eine Schnellspeicherung. Der entscheidende Nachteilist jedoch, dass bei einer Schnellspeicherung die Datei unter UmständenTextfragmente enthalten kann, die der Verfasser nicht weitergeben möch-te.

- Eine weitere Möglichkeit, wie Informationen weitergegeben werden kön-nen, die nicht für Externe bestimmt sind, stellen Funktionen dar, die esbeispielsweise erlauben, in ein Textdokument oder eine Präsentation ei-ne Tabelle aus einem Tabellenkalkulationsdokument so einzubetten, dassdie Tabelle direkt im Textdokument bearbeitet werden kann. Wird ein sol-ches Textdokument weitergegeben, so können unter Umständen sehr vielmehr Informationen aus dem Tabellenkalkulationsdokument übertragenwerden, als im Textdokument sichtbar sind.

- Auf z/OS-Systemen werden gelöschte Member nicht sofort in der Biblio-thek (PDS - Partitioned Dataset) überschrieben. Lediglich der Eintrag desMembers im Verzeichnis (Directory) des PDS wird gelöscht. Erst wennim PDS freier Speicherplatz benötigt wird, werden die Informationen desalten Members überschrieben. Noch nicht überschriebene Daten lassensich mit Hilfsprogrammen auslesen.

- Werden in z/OS-Systemen Dateien auf einer Festplatte gelöscht, so wirddie Datei im Volume Table of Content (VTOC) als gelöscht gekennzeich-net, die Datei selbst auf der Festplatte jedoch nicht gelöscht. Die Dateiwird erst überschrieben, wenn neue Daten auf der Festplatte gespeichertwerden sollen und kein freier Platz verfügbar ist. Gelingt es, die Speicher-stelle der Datei aus dem VTOC auszulesen, so ist es möglich, die Datei



mit speziellen Programmen zu editieren und wieder herzustellen. Dies giltebenso für Bänder, die zwar als Leer-Bänder gekennzeichnet, aber nochnicht überschrieben sind.

Restinformationen auf Datenträgern

Bei den meisten Dateisystemen werden Dateien, die vom Benutzer über einenLöschbefehl gelöscht werden, nicht wirklich in dem Sinn gelöscht, dass dieInformation anschließend nicht mehr vorhanden ist. Normalerweise werdenlediglich die Verweise auf die Datei aus den Verwaltungsinformationen desDateisystems (etwa aus der Dateizuordnungstabelle (File Allocation Table)beim FAT-Dateisystem) gelöscht und die zu der Datei gehörenden Blöcke als"frei" markiert. Der tatsächliche Inhalt der Blöcke auf dem Datenträger bleibtjedoch erhalten und kann mit entsprechenden Werkzeugen rekonstruiert wer-den.

Wenn Datenträger an Dritte weitergegeben werden, beispielsweise

- wenn ein Rechner ausinventarisiert wurde und verkauft wird,- wenn ein defektes Gerät zur Reparatur gegeben oder im Rahmen der Ga-

rantie ausgetauscht wird oder- wenn ein Datenträger im Rahmen des Datenträgeraustauschs an einen

Geschäftspartner weitergegeben wird

können auf diese Weise sensitive Informationen nach außen gelangen.

Beispiele:- Die Forscher Simson Garfinkel und Abhi Shelat vom MIT kauften zwischen

2000 und 2002 bei verschiedenen Händlern über das Online-Auktions-haus eBay eine größere Anzahl gebrauchter Festplatten und untersuchtendiese auf enthaltene Restinformationen. Sie fanden eine erschreckendeMenge an Daten, beispielsweise

- interne Vermerke von Unternehmen, bei denen es um Personalsa-chen ging,

- eine große Anzahl von Kreditkartennummern,- medizinische Informationen,- E-Mails

und vieles mehr. Ihre Ergebnisse veröffentlichten sie in einem Journal derIEEE.

- Ein Benutzer verwendete einen alternativen Editor und entdeckte per Zu-fall, dass eine kurz vor der Veröffentlichung stehende Datei diverse URLsenthielt, inklusive Benutzername und Passwort für einen WWW-Server.

- Eine Behörde hatte mit dem Programm Microsoft Powerpoint erstellte Prä-sentationen in Dateiform an Externe weitergegeben. Später stellte sichheraus, dass neben den Präsentationen auch Informationen über dieRechnerumgebung des Benutzers mitgeliefert worden waren, wie etwadarüber, welche Newsgruppen ein Benutzer abonniert hat und welcheNews er schon gelesen hat.

- Zwei Verkäufer konkurrierender Firmen tauschten ihre Präsentationenaus, die sie bei einer Veranstaltung gehalten hatten. Eines der Power-point-Dokumente enthielt eine kleine Tabelle mit Endkunden-Preisen fürdie Produkte der einen Firma. Beim Öffnen der Präsentation entdeckteder Empfänger, dass diese kleine Tabelle Teil eines sehr umfangreichenTabellenkalkulationsdokuments war, das in die Präsentation eingebettetworden war, und das die gesamte Preiskalkulation des Konkurrenzunter-nehmens enthielt.



G 2.67 Ungeeignete Verwaltung vonZugangs- und Zugriffsrechten

Wenn die Vergabe von Zugangs- und Zugriffsrechten schlecht geregelt ist,führt das schnell zu gravierenden Sicherheitslücken, z. B. durch Wildwuchs inder Rechtevergabe.

In vielen Institutionen ist die Verwaltung von Zugangs- und Zugriffsrechteneine extrem arbeitsintensive Aufgabe, weil sie schlecht geregelt ist oder diefalschen Tools dafür eingesetzt werden. Dadurch kann z. B. viel "Handarbeit"erforderlich sein, die gleichzeitig wiederum sehr fehleranfällig ist. Außerdemsind in diesem Prozess dann auch häufig viele unterschiedliche Rollen undPersonengruppen eingebunden, sodass hier auch leicht der Überblick überdurchgeführte Aufgaben verloren geht.

Weiterhin gibt es auch Institutionen, in denen kein Überblick über alle auf denverschiedenen IT-Systemen eingerichteten Benutzer und deren Rechteprofilvorhanden ist. Typischerweise führt das dazu, dass sich Accounts finden vonBenutzern, die die Behörde bzw. das Unternehmen längst verlassen habenoder die durch wechselnde Tätigkeiten zu viele Rechte aufgehäuft haben.

Wenn die Tools zur Verwaltung von Zugangs- und Zugriffsrechten schlechtausgewählt wurden, sind diese oft nicht flexibel genug, um auf Änderungenin der Organisationsstruktur oder auf Wechsel der IT-Systeme angepasst zuwerden.

Die Rollentrennung von Benutzern kann falsch vorgenommen worden sein,so dass Sicherheitslücken entstehen, beispielsweise durch falsche Zuordnungvon Benutzern in Gruppen oder zu großzügige Rechtevergabe. Benutzer kön-nen Rollen zugeordnet werden, die nicht ihren Aufgaben entsprechen (zu vieloder zu wenig Rechte) oder die sie aufgrund ihrer Aufgaben nicht haben dür-fen (Rollenkonflikte).



G 2.82 Fehlerhafte Planung desAufstellungsortes von Speicher-und Archivsystemen

Aufgrund der Sensitivität der gespeicherten Daten sowie der sehr langen Auf-bewahrungszeit sind bei Speicher- oder Archivsystemen erhebliche Anforde-rungen an die Qualität der Datenspeicherung zu stellen. Die Wahl des Auf-stellungsortes für das Speicher- oder das Archivsystem hat hierauf hohen Ein-fluss.

In diesem Zusammenhang sind folgende potentielle Sicherheitsprobleme zubeachten:

- Unzulängliche klimatische BedingungenEine zu hohe oder zu niedrige Temperatur kann ebenso wie eine zu hoheLuftfeuchtigkeit zu Fehlfunktionen in technischen Komponenten von Ar-chiv- und Speichersystemen und zur Beschädigung von Archiv- und Spei-chermedien führen. Häufige Schwankungen der klimatischen Bedingun-gen verstärken diesen Effekt. Auch durch Sekundärschäden können der-artige Klimabelastungen hervorgerufen werden. Ein Beispiel dafür ist dieAusdünstung von Wänden, die nach einem Brand im Nachbarraum auf-treten kann.

- Unzureichender physikalischer SchutzDurch unzureichenden Schutz des Speicher- oder Archivsystems gegenunbefugten Zutritt und Zugriff können vorsätzliche Handlungen (z. B. Die-bstahl, Manipulation oder Sabotage) begünstigt werden.

- Unzureichender Schutz gegen sonstige UmgebungseinflüsseAuch durch sonstige Umgebungseinflüsse (z. B. Erschütterungen oder ei-ne hohe Staubbelastung) können Schäden an technischen Komponentendes Archivsystems oder an Speichermedien hervorgerufen werden. Be-sonders ärgerlich ist das, wenn die schädigenden Einflüsse sogar vorher-sehbar waren, wie z. B. bei Bauarbeiten.

Beispiel:

Durch Ansiedlung des zentralen IT-Bereichs nahe an Produktionsanlagenkommt es dort gelegentlich zu Erschütterungen. Als Folge treten immer wie-der Störungen in den technischen Komponenten des Archivsystems auf, dasebenfalls im IT-Bereich betrieben wird.



G 2.103 Unzureichende Schulung derMitarbeiter

IT-Benutzer aller Art werden häufig zu wenig in der Bedienung der von ih-nen eingesetzten IT-Systeme geschult. Dies trifft leider sogar öfters auf Ad-ministratoren und Benutzerbetreuer zu. Vielfach werden teure Systeme undAnwendungen angeschafft, aber keine oder nur unzureichend Mittel für dieSchulung der IT-Benutzer bereitgestellt.

Dies kann durch unabsichtliche Fehlbedienungen, falsche Konfiguration undungeeignete Betriebsmittel zu gravierenden Sicherheitsproblemen führen.Häufig wenden Benutzer neu eingeführte Sicherheitsprogramme deswegennicht an, weil sie nicht wissen, wie sie bedient werden und eine selbstständigeEinarbeitung oft als zu zeitaufwendig im täglichen Arbeitsablauf gesehen wird.Daher reicht die Beschaffung und Installation einer Sicherheitssoftware nochlange nicht aus.

Beispiele:- Während der Datenerfassung erschien eine dem Benutzer nicht bekannte

Fehlermeldung. Da bei den meisten Fehlermeldungen das Anklicken von"ok" bisher keinen Schaden verursachte, wählte er an diesem Fall auch"ok". Nur diesmal bewirkte dies das Herunterfahren des Systems und folg-lich den Verlust der bis dahin eingegebenen Daten.

- Ein teures Firewall-System wurde beschafft. Der Administrator eines an-deren IT-Systems wurde "durch Handauflegen" zum Administrator die-ses Firewall-Systems bestimmt. Da er als unabkömmlich galt und alleverfügbaren Mittel für die System-Beschaffung verwendet worden waren,wurde er aber weder in der Bedienung der System-Plattform noch fürden eingesetzten Firewall-Typ ausgebildet. Externe Seminare wurden ausGeldmangel verweigert, nicht einmal zusätzliche Handbücher angeschafft.Zwei Monate nach Inbetriebnahme des Firewall-Systems stellte sich her-aus, dass durch eine Fehlkonfiguration der Firewall interne Systeme ausdem Internet frei zugänglich waren.

- In einem Unternehmen wurde die Migration auf ein neues Betriebssystemvorbereitet. Der dafür verantwortliche Mitarbeiter war zwar ein ausgezeich-neter Kenner der bis dahin eingesetzten Plattform, kannte sich aber mitden diskutierten neuen Systemen nicht aus und erhielt auch keine dementsprechende Schulung. Daher besuchte er einige kostenfreie Veranstal-tungen eines Herstellers, dessen Produkte er auch danach favorisierte.Dies führte zu einer kostenintensiven Fehlentscheidung durch Einführungeines ungeeigneten Produktes.

- Für die Internet-Nutzung während der Dienstreisen wurden auf den Note-books der Mitarbeiter Personal Firewalls installiert. Die Mitarbeiter wurdennicht dazu geschult, eine Abstimmung der Einstellungen der Firewall mitden Bedürfnissen der Mitarbeiter fand nicht statt. Viele Mitarbeiter habendaraufhin die Firewall abgeschaltet, um problemlos alle Internet-Seiten zuerreichen, die sie brauchten. Das Ergebnis war, dass schon nach einigenWochen viele der Rechner mit Schadprogrammen verseucht waren. Ne-ben dem Datenverlust war der Ansehensschaden erheblich, da sich einSchadprogramm über Mails an Kunden weitergesendet hatte.



G 2.109 Fehlende oder unzureichendePlanung der Speicherlösung

Der Betrieb von Speicherlösungen erfordert sorgfältige Planung, Installationund Konfiguration, um einen störungsfreien Einsatz gewährleisten zu kön-nen. Mögliche Gefährdungen aufgrund fehlender oder unzureichender Pla-nung können in folgenden Aspekten Ausdruck finden:

- Die Anforderungen einer Institution hinsichtlich des benötigten Speicher-platzes, ausreichender Performance sowie der Verfügbarkeit eingesetz-ter Speicherlösungen steigen stetig. Bei unzureichender Dimensionierungder eingesetzten Speicherlösung kann diesen wachsenden Anforderun-gen nicht in jedem Fall entsprochen werden.Beispiel: Je nach Anwendungsanforderung ist die bereitgestellte I/O-Per-formance auf den Platten ein limitierender Faktor für das Gesamtsystem.

- Die Gründe für eine unzureichende Dimensionierung bei der Planung vonSpeicherlösungen liegen in der Regel in einer fehlenden Ist-Analyse. Auchdie fehlende oder unzureichende Trendanalyse bzw. Prognose bezüglichzukünftiger Entwicklungen innerhalb des eigenen IT-Verbundes trägt unterUmständen zum Einsatz falsch dimensionierter Speicherlösungen bei.

- In virtuellen Speicherumgebungen bietet das sogenannte Thin Provisio-ning die Möglichkeit, ein kostensparendes Verfahren zur Bereitstellungvon Speicherkapazität einzusetzen. Thin Provisioning macht sich zunutze,dass moderne Speicherlösungen virtuelle Festplatten zur Verfügung stel-len, deren Kapazität nach außen größer erscheint als physisch vorhanden.Überschreitet die vom Server physisch genutzte Kapazität einen bestimm-ten Schwellenwert, wird aus einem vorhandenen Speicherpool zusätzlichfreie Kapazität für den Abnehmer bereitgestellt. Ist der Schwellenwert auf-grund unzureichender Planung etwa zu niedrig ausgelegt oder wird dieservon vielen Abnehmern innerhalb eines kurzen Zeitraums überschritten,kann dies zu einer Überbuchung der insgesamt verfügbaren Speicherka-pazitäten führen.

- Ein falsch gewähltes SAN-Design kann als Folge mangelnder oder unzu-reichender Planung der Speicherlösung eine Gefährdung für die Institutiondarstellen. Fehlende SAN-Ports, schlechte Leitungskapazität durch zu ho-he Dämpfung, fehlende Inter-Switch-Link-Verbindungen (ISL-Verbindun-gen) sowie eine unzureichende Lastverteilung an den SAN-Switchen kön-nen einen reibungslosen Betrieb verhindern und beispielsweise die Ver-letzung vertraglicher Vereinbarungen und somit finanzielle Schäden mitsich bringen.

- Im Falle der Notwendigkeit zum Aufbau und Betrieb einer hochverfügba-ren Speicherlösung sollte das Hauptaugenmerk auf eine sorgfältige undausführliche Planung gelegt werden. Vorrangiges Ziel ist die Vermeidungvon sogenannten Single Points of Failure (SPOF), also der Abhängigkeiteiner an sich redundant ausgelegten Infrastruktur von der Funktion einereinzelnen Komponente.

- Die Anforderungen einer Anwendung an deren Performance sowie Inter-operabilitätsanforderungen bezüglich der vorhandenen Hard- und Softwa-re können den Einsatz von bestimmten Produkten erzwingen. Wenn dieseAspekte nicht rechtzeitig in der Planung berücksichtigt werden, kann diesteure und ineffiziente Korrekturen während der Realisierung, Verzögerun-gen im Einsatz oder erhebliche Störungen im Betrieb als Folge haben.

- Die fehlende Mandantenfähigkeit der gewählten Speicherlösung kann un-ter Umständen ebenfalls eine Gefährdung für die Institution darstellen. Invielen Institutionen ist die IT heute Dienstleister und stellt (internen) Kun-den Speicherplatz zur Verfügung. Damit besteht insbesondere auch die



Notwendigkeit zur Berücksichtigung des unterschiedlichen Schutzbedar-fes für die zu speichernden Daten dieser (internen) Kunden, also beispiels-weise für einzelne Unternehmensbereiche.

- Eine fehlende oder unzureichende Sicherheitskonzeption sowie die feh-lende oder unzureichende Dokumentation können ebenfalls Folgen man-gelnder Planung sein.



G 2.182 Fehlendes oder unzureichendesBetreiberkonzept fürSpeicherlösungen

Die Planung, Beschaffung und der Betrieb von Speicherlösungen hinsichtlichderen Dimensionierung sowie der Anforderungen an Verfügbarkeit und Per-formance gestalten sich für Institutionen zunehmend komplex und sind sehranspruchsvoll. Dies bedingt, dass auf strategischer Ebene die Betriebsart ei-ner Speicherlösung geplant und festgelegt werden muss.

Dabei sind sowohl unterschiedliche Ausprägungen einer Betriebsart (z. B. Be-trieb durch eigenes Personal oder Betrieb durch Dritte mit bzw. ohne Über-gabe der Betriebsverantwortung) als auch die Möglichkeit zur Unterbringungder Speicherlösung in den eigenen Räumen bzw. bei einem Dienstleister zuunterscheiden.

Liegen keine Regelungen zur festgelegten Betriebsart, etwa in Form eines Be-treiberkonzeptes vor, kann dies weitreichende Störungen im Betrieb zur Folgehaben, die sich mittelbar auf die Vertraulichkeit, Verfügbarkeit und Integritätder gespeicherten Daten auswirken können. Unklare Zuständigkeiten im Falleeiner Systemstörung sind nur ein Beispiel für mögliche Probleme.

Der Betrieb einer Speicherlösung basiert in der Regel auf der Erstellung einesServicekatalogs, mit dessen Hilfe angebotene Services bzw. feste Vereinba-rungen zu Serviceleistungen, sogenannte Service Level Agreements (SLAs)bzw. Operational Level Agreements (OLAs) bei internen Kunden, beschriebenwerden.

Ein fehlender Servicekatalog bringt sowohl für den Anbieter einer Speicherlö-sung als auch für den Anwender erhebliche Nachteile mit sich, da getroffeneVereinbarungen nicht nachvollzogen werden können und Unsicherheit bezüg-lich der Rechte und Pflichten entsteht. Ist nicht festgelegt, welchen Kriterienein Service üblicherweise genügen muss, kann die Servicequalität nicht ge-messen und die Serviceerbringung nicht sichergestellt werden.



G 2.183 Fehlendes oder unzureichendesZonenkonzept

Ein Zonenkonzept dient dazu, ein oder mehrere Sicherheitsniveaus einzelnerSysteme innerhalb einer Institution herzustellen und aufrechtzuerhalten. Zieleines Zonenkonzeptes ist dabei nicht die Trennung unterschiedlicher Mandan-ten, sondern die Trennung von Zonen, denen ein unterschiedlicher Schutzbe-darf zugesprochen wurde. Mit der Einführung eines Zonenkonzeptes könnenbestehende Systeme, basierend auf ihrem Schutzbedarf, standardisiert einemSicherheitsniveau zugeordnet werden.

Ein Zonenkonzept kann unterschiedliche Ausprägungen annehmen. Häufig istdabei eine Unterteilung in Netzzonen und Storagezonen anzutreffen, die inder Praxis jedoch unterschiedlich restriktiv umgesetzt ist.

Es gilt zu beachten, dass der Begriff Zoning innerhalb eines SAN-Speicher-netzes die möglichen Verbindungen zwischen einem Speichersystem und denServern beschreibt und mit einem Zonenkonzept nur namentlich verwandt ist.

Ein fehlendes oder unzureichendes Zonenkonzept kann zur Folge haben,dass unterschiedliche Anforderungen an das Sicherheitsniveau von Systemenhinsichtlich Verfügbarkeit, Vertraulichkeit oder Integrität nicht oder nur teilwei-se erfüllt werden können.

Des Weiteren können Mängel in der Umsetzung des Zonenkonzeptes dazuführen, dass der einzig vorgesehene und erlaubte Zugriffsweg auf Systememit unterschiedlichem Sicherheitsniveau umgangen werden kann. Ein Beispielhierfür ist die Verletzung von Regelungen zur Kommunikationsmatrix, die Auf-schluss darüber geben, welche Systeme ohne zusätzliche Authentisierungs-oder Autorisierungsmaßnahmen auf Systeme außerhalb ihrer eigenen Zonezugreifen dürfen.

Die Umsetzung eines bestehenden Zonenkonzeptes basiert auf der geeigne-ten Dokumentation der festgelegten Regeln hinsichtlich der erlaubten Zugriffs-wege. Fehlende oder unzureichende Dokumentation kann dazu führen, dassVerstöße gegen die bestehende Kommunikationsmatrix und damit die Vermi-schung von Systemen mit unterschiedlichem Schutzbedarf nicht oder nur ver-spätet erkannt und beseitigt werden können.



G 2.184 Fehlendes oder unzureichendesRechte- und Rollenkonzept inCloud-Infrastrukturen

Im Cloud-Umfeld ist die gemeinschaftliche Nutzung von IT-Systemen durchmehrere Institutionen weit verbreitet. Wird in einem solchen Umfeld gänzlichauf die Durchsetzung eines Rollen- und Rechtekonzeptes verzichtet oder istdieses unzureichend umgesetzt, stellt dies eine Gefährdung für die Institutiondar. Der unberechtigte Zugriff auf Anwendungsdaten oder auf die Komponen-ten einer Speicherlösung können die Folge sein.

Die Gefahr solcher unberechtigten Zugriffe besteht dabei immer innerhalb ei-nes Mandanten oder auch über mehrere Mandanten hinweg (mandantenüber-greifend). Es ist daher notwendig, ein ausreichendes Rechte- und Rollenkon-zept einzusetzen.

Folgende Ausprägungen für unberechtigte Zugriffe in Cloud-Infrastrukturensind zu unterscheiden:

- Ein Benutzer kann auf die Infrastruktur des Providers zugreifen und in-nerhalb dieser gegebenenfalls Manipulationen durchführen oder Daten lö-schen.

- Ein Benutzer kann auf die Daten eines anderen Anwenders zugreifen unddiese manipulieren oder löschen.

Je nach Ausprägung des Zugriffs können alle drei Sicherheitsziele (Vertrau-lichkeit, Verfügbarkeit und Integrität der Informationen) gefährdet sein.

Beispiel:- Eine Institution nutzt Cloud-Services, um ihre verfügbare Speicherkapa-

zität flexibel zu erweitern. Um die Dienste zu verwalten bzw. zu steuern,ist aufseiten der Institution die Rolle eines Cloud-Administrators vorgese-hen. Diese Rolle und die damit verbundenen Rechte sind unzureichenddefiniert. In der Folge administriert der Mitarbeiter durch Vererbung ausder Cloud-Administrationskonsole heraus die eingesetzte Speicherlösung(unbeabsichtigt) mit und verändert dabei beispielsweise die Einstellungenzum LUN-Masking bzw. LUN-Mapping. Durch diese fehlerhaften Einstel-lungen erhält ein Benutzer unberechtigt Zugriff auf Daten.



G 2.185 Fehlende oder unzureichendeSoftwarewartung (Maintenance)und fehlendes oderunzureichendes Patchlevel-Management

Softwarewartung ist auch unter dem englischen Begriff Software Maintenancebekannt. Hersteller verfolgen mit der Bereitstellung von Softwareaktualisierun-gen (Patches) das Ziel, Änderungen und Verbesserungen an implementier-ten Softwarelösungen auch dann noch vorzunehmen, nachdem diese bereitsausgeliefert sind. Auf diesem Weg werden bekannte Fehler behoben, die Lei-stungsfähigkeit verbessert und dem Einsatz neuer Technik wie z. B. der Nut-zung neuer Festplattengenerationen (SSD, Flash etc.) Rechnung getragen.

Werden Systeme nicht oder lediglich unzureichend gewartet, indem beispiels-weise verfügbare Sicherheitspatches nicht eingespielt werden oder auf dieAktualisierung der Firmware verzichtet wird, kann dies zur Instabilität der Sy-steme und damit zum Ausfall der Speicherlösung führen.

In einigen Fällen ist der reibungslose Betrieb einer Speicherlösung von derEinhaltung einer sogenannten Kompatibilitätsmatrix, bereitgestellt durch denHersteller, abhängig. In der Kompatibilitätsmatrix werden die in einer Spei-cherlösung einsetzbaren Hard- und Softwarestände in ihrer wechselseitigenAbhängigkeit beschrieben. Weicht der Firmwarestand einzelner Komponen-ten von dieser Matrix ab, können Ausfälle oder Performance-Einbußen dieFolge sein.

Die Durchführung von Wartungsarbeiten sowie das Patchlevel-Managementsind eng mit einem etablierten Verfahren zum Änderungsmanagement ver-bunden. Fehlt dieses, können vorgenommene Änderungen und damit in Zu-sammenhang stehende Fehler nur schwer nachvollzogen werden. AktuelleVersionen eingesetzter Soft- oder Firmware sind im Falle eines fehlenden Än-derungsmanagements nur mit erhöhten Aufwänden zu ermitteln.

Der langfristige sichere Betrieb einer Speicherlösung kann durch einen feh-lenden Wartungsvertrag ebenfalls gefährdet werden, da die Kompatibilität zuaktuellen Komponenten unter Umständen ein vorheriges Upgrade auf die ak-tuellste Firmware voraussetzt. Ohne Wartungsvertrag ist ein solches Upgradeunter Umständen gar nicht möglich oder mit erheblichen Kosten verbunden.

Weitere Hinweise für bestehende Gefährdungen im Zusammenhang mit derWartung von Hardware können der G 2.5 Fehlende oder unzureichende War-tung entnommen werden.



G 2.186 Fehlende oder unzureichendeRegelungen / keineklare Abgrenzung vonVerantwortlichkeiten beiSpeicherlösungen

Der Einsatz zentraler Speicherlösungen bringt steigende Anforderungen andie Administration mit sich. Diese begründen sich sowohl durch eine erhöhteKomplexität moderner Speicherlösungen als auch dadurch, dass zunehmendIP-Netze und Fibre-Channel-Netze innerhalb einer Speicherlösung miteinan-der verschmelzen.

Hinzu kommt, dass vermehrt Storage-Virtualisierung sowie Storage-Automa-tion eingesetzt werden. Ferner verändert sich die Architektur von Speicherlö-sungen, was sich auch auf die Administration und damit auf die Anforderun-gen an die Administratoren auswirkt.

Existieren in diesem Zusammenhang keine oder nur unzureichende Regelun-gen hinsichtlich der Abgrenzung von Verantwortlichkeiten, besteht die Gefahrvon Fehlkonfigurationen durch unzureichende Kenntnisse. Folgende Ausprä-gungen sind hier häufig zu beobachten:

- Administriert ein Netzadministrator FCoE-Switche, so erhält er möglicher-weise Zugriff auf Komponenten, für deren Administration er nicht ausgebil-det ist. Ein solcher Vorgang kann Fehlfunktionen oder Fehlkonfigurationengenerieren, die bis hin zum Ausfall des Gesamtsystems führen können.

- Oftmals herrscht ein Silodenken zwischen Netzadministratoren und Ad-ministratoren der Speicherlösungen. Jeder Bereich beansprucht dabei er-weiterte Zugriffsrechte zunächst einmal für sich, ohne dem Kenntnisstandder jeweils anderen Mitarbeiter Beachtung zu schenken. Durch die zuneh-mende Verschmelzung der IP- und FC-SAN-Welten zu einem vereintenNetz (unified network) birgt dieses Silodenken jedoch Gefahren, da tech-nische Abhängigkeiten eine engere Zusammenarbeit und Abstimmung derAdministratoren untereinander bedingen.



G 2.187 Fehlendes oder unzureichendesmandantenfähigesAdministrationskonzept fürSpeicherlösungen

Bei der gemeinsamen Nutzung von IT-Systemen durch unterschiedliche Insti-tutionen, wie sie im Cloud Umfeld weit verbreitet ist, existiert, bedingt durchein fehlendes oder unzureichendes Rollenkonzept, die Gefahr eines mandan-tenübergreifenden administrativen Zugriffs. Da Administratoren in der Regelüber sehr weitreichende Berechtigungen verfügen, stellt dies eine erheblicheBedrohung aller Sicherheitsziele einer Institution dar.

Insbesondere im Zusammenhang mit dem Servicemodell Infrastructure as aService (IaaS), das häufig in Verbindung mit Cloud Storage zur Anwendungkommt, besteht daher die Notwendigkeit zum Einsatz eines mandantenfähi-gen Administrationskonzeptes.

Aus Sicherheitssicht sind folgende mögliche Ausprägungen eines mandan-tenfähigen Administrationskonzeptes zu unterscheiden:

- Der Betreiber einer Speicherlösung trennt seine Administratoren entspre-chend seiner Mandanten. Existiert für dieses Vorgehen kein Konzept oderist dieses unzureichend umgesetzt, besteht die Gefahr, dass der Admini-strator für Mandant A auf die Daten von Mandant B zugreift.

- Die Mandanten erhalten selbst administrative Rechte für ihren jeweiligenBereich. Bei nicht vorhandenem oder unzureichend umgesetztem Konzeptbesteht die Gefahr, dass Mitarbeiter von Mandant A direkt auf die Datenvon Mandant B zugreifen können.

Kommen bei einer Institution Speichersysteme zum Einsatz, die mehrerenMandanten unabhängig voneinander Speicher zur Verfügung stellen (z. B. vir-tuelle Fileserver in einer NAS-Umgebung) so kann durch ein fehlendes Rol-lenkonzept die Gefahr eines mandatenübergreifenden administrativen Zugriffsgegeben sein.

Gefährdungskatalog Menschliche Fehlhandlungen G 3.9 Bemerkungen


G 3.9 Fehlerhafte Administration vonIT-Systemen

Eine Administration beeinträchtigt die Sicherheit eines IT-Systems, wenn da-durch Sicherheitsmaßnahmen missachtet oder umgangen werden. Jede Mo-difikation von Sicherheitseinstellungen und die Erweiterung von Zugriffsrech-ten stellt eine potenzielle Gefährdung der Gesamtsicherheit dar.

Durch die fehlerhafte Installation von Software können Sicherheitsproblemeentstehen. Standard-Installationen von Betriebssystemen oder Systempro-grammen weisen in den seltensten Fällen alle Merkmale einer sicheren Kon-figuration auf. Mangelnde Anpassungen an die konkreten Sicherheitsbedürf-nisse können hier ein erhebliches Risiko darstellen. Die Gefahr von Fehlkonfi-gurationen besteht insbesondere bei komplexen Sicherheitssystemen, bei de-nen sich Systemfunktionen oft gegenseitig beeinflussen.

Die Ursachen für fehlerhaft ausgeführte Administrationstätigkeiten könnenvielfältigen Ursprungs sein. Denkbar sind hier beispielsweise Fehlbedienun-gen, die durch nachfolgende Aspekte hervorgerufen werden.

- Die Prozessdokumentation fehlt oder ist nicht aktualisiert. Sie gibt dem Ad-ministrator keinen Aufschluss über die Handhabung notwendiger Sicher-heitseinstellungen.

- Die hohe technische Komplexität des IT-Systems führt dazu, dass der Ad-ministrator die Auswirkungen seiner Tätigkeiten in ihrer Gesamtheit nichtmehr überschauen kann. Durch die Anpassung eines Systemparameterswerden weitere Parameter beeinflusst, die unter Umständen ursprünglichnicht im Zusammenhang standen.

- Die fehlende Standardisierung eines IT-Systems oder seiner Komponen-ten führt dazu, dass dieses auf die Einstellungen eines Administrators an-ders reagiert als gewünscht.

- Bedingt durch die fehlende Umsetzung des 4-Augen-Prinzips bleibt derBedienungsfehler eines Administrators zunächst unentdeckt.

- Die eingesetzten Administratoren verfügen über unzureichende Kenntnis-se im Zusammenhang mit der Bedienung der eingesetzten IT-Systeme.

- Die falsche Interpretation von aufgezeichneten Ereignissen führt zur Aus-führung administrativer Arbeiten, die sich in der Folge als fehlerhaft erwei-sen. Die tatsächliche Ursache für das Ereignis wird dadurch zunächst nichtuntersucht.

Die Durchführung von Wartungs- bzw. Betriebsarbeiten erfolgt in der Regelauf Basis administrativer Berechtigungen. Mögliche Gefährdungen für die In-stitution ergeben sich hierbei beispielsweise durch:

- die Nichteinhaltung von Standard-Arbeitsanweisungen (Standard Opera-ting Procedures,SOP),

- eine falsche Patch-Reihenfolge,- das Einspielen von Patches ohne das Durchlaufen eines vorherigen Test-

und Freigabeverfahrens,- die Nichtbeachtung der Kompatibilitätsmatrix des Herstellers.

Die Erstellung und Pflege eines entsprechenden Betriebshandbuchs ist dieVoraussetzung für die Nachvollziehbarkeit der Konfiguration und Funktions-weise der eingesetzten IT-Systeme. Fehlt dieses, können Fehler unter Um-ständen verzögert nachvollzogen und beseitigt werden.



G 3.16 Fehlerhafte Administration vonZugangs- und Zugriffsrechten

Zugangsrechte zu einem IT-System und Zugriffsrechte auf gespeicherte Da-ten und IT-Anwendungen dürfen nur in dem Umfang eingeräumt werden, wiesie für die Wahrnehmung der Aufgaben erforderlich sind. Werden diese Rech-te fehlerhaft administriert, so kommt es zu Betriebsstörungen, falls erforderli-che Rechte nicht zugewiesen wurden, bzw. zu Sicherheitslücken, falls überdie notwendigen Rechte hinaus weitere vergeben werden.

Beispiel:

Durch eine fehlerhafte Administration der Zugriffsrechte hat ein Sachbearbei-ter die Möglichkeit, auf die Protokolldaten zuzugreifen. Durch gezieltes Lö-schen einzelner Einträge ist es ihm daher möglich, seine Manipulationsversu-che am Rechner zu verschleiern, da sie in der Protokolldatei nicht mehr er-scheinen.



G 3.24 UnbeabsichtigteDatenmanipulation

Je umfangreichere Zugriffsberechtigungen auf eine Datenbank für die Anwen-der bestehen, um so größer ist auch das Risiko einer unbeabsichtigten Da-tenmanipulation. Dies kann prinzipiell von keiner Anwendung verhindert wer-den. Die grundsätzlichen Ursachen für unbeabsichtigte Datenmanipulationenkönnen z. B. sein:

- mangelhafte oder fehlende Fachkenntnisse,- mangelhafte oder fehlende Kenntnisse der Anwendung,- zu umfangreiche Zugriffsberechtigungen und- Fahrlässigkeit (z. B. das Verlassen des Arbeitsplatzes ohne korrekte Be-

endigung der Anwendung).



G 3.38 Konfigurations- undBedienungsfehler

Konfigurationsfehler entstehen durch eine falsche oder nicht vollständige Ein-stellung von Parametern und Optionen, mit denen ein Programm gestartetwird. In diese Gruppe fallen unter anderem falsch gesetzte Zugriffsrechte fürDateien. Bei Bedienungsfehlern sind nicht einzelne Einstellungen falsch, son-dern die IT-Systeme oder IT-Anwendungen werden falsch behandelt. Ein Bei-spiel hierfür ist das Starten von Programmen, die für den Einsatzzweck desRechners nicht notwendig sind, aber von einem Angreifer missbraucht werdenkönnen.

Beispiele für aktuelle Konfigurations- bzw. Bedienungsfehler sind das Spei-chern von Passwörtern auf einem PC, auf dem ungeprüfte Software aus demInternet ausgeführt wird, oder das Laden und Ausführen von schadhaften Acti-veX-Controls. Diese Programme, die unter anderem, die Aufgabe haben, We-bseiten durch dynamische Inhalte attraktiver zu machen, werden mit den glei-chen Rechten ausgeführt, die auch der Benutzer hat. Sie können beliebig Da-ten löschen, verändern oder versenden.

Viele Programme, die für die ungehinderte Weitergabe von Informationen in ei-nem offenen Umfeld gedacht waren, können bei falscher Konfiguration poten-ziellen Angreifern Daten zu Missbrauchszwecken liefern. So kann beispiels-weise der finger-Dienst darüber informieren, wie lange ein Benutzer bereitsam Rechner sitzt. Aber auch Browser übermitteln bei jeder Abfrage einer Da-tei eine Reihe von Informationen an den Webserver (z. B. die Version desBrowsers und des verwendeten Betriebssystems, den Namen und die Inter-net-Adresse des PCs). In diesem Zusammenhang sind auch die Cookies zunennen. Hierbei handelt es sich um Dateien, in denen Webserver-BetreiberDaten über den Benutzer auf dessen Rechner speichern. Diese Daten könnenbeim nächsten Besuch des Servers abgerufen und vom Server-Betreiber füreine Analyse, der vom Benutzer vorher auf dem Server besuchten Webseiten,verwendet werden.

Der Einsatz eines Domain Name Systems stellt eine weitere Gefahrenquelledar. Zum einen ermöglicht ein falsch konfigurierter DNS-Server die Abfragevon vielen Informationen über ein lokales Netz. Zum anderen hat ein Angreiferdurch die Übernahme dieses Servers die Möglichkeit, gefälschte IP-Adressenzu verschicken, sodass jeglicher Verkehr von ihm kontrolliert werden kann.

Eine große Bedrohung geht auch von den automatisch ausführbaren Inhalten(Executable Content) in E-Mails oder HTML-Seiten aus. Dies ist unter demStichwort Content-Security-Problem bekannt. Dateien, die aus dem Internetgeholt werden, können Code enthalten, der bereits beim "Betrachten" und oh-ne Rückfrage beim Benutzer ausgeführt wird. Dies ist z. B. bei Makros in Of-fice-Dateien der Fall und wurde zum Erstellen von sogenannten Makro-Virenausgenutzt. Auch Programmiersprachen und -schnittstellen wie ActiveX, Ja-vascript oder Java, die für Anwendungen im Internet entwickelt worden sind,besitzen bei falscher Implementierung der Kontrollfunktionen ein Schadpoten-zial.

Die Verfügbarkeit des Sicherheitssystems RACF ist bei z/OS-Betriebssyste-men von zentraler Bedeutung für die Verfügbarkeit des gesamten Systems.Durch unsachgemäßen Einsatz von z/OS-Utilities bei der RACF-Datenbank-sicherung oder fehlerhafte Bedienung der RACF-Kommandos kann diese ein-geschränkt werden.



G 3.79 Fehlerhafte Zuordnung vonRessourcen des SAN

Betriebssysteme reagieren unterschiedlich auf sichtbare Speicherressourcen.Wenn keine eindeutige und starke Zuordnung von Servern und Speicherres-sourcen vorgenommen wird, können unautorisierte Zugriffe auf Speicherres-sourcen, z. B. durch andere Server, das Schutzkonzept auf Ebene des Betrie-bssystems oder der Anwendung unterlaufen.

An dieser Stelle ist nicht nur der vorsätzliche Angriff zu betrachten, bei dem einAngreifer versucht, Lücken der Konfiguration für seine Absichten auszunut-zen. Beachtlich ist auch die Eigenart mancher Betriebssysteme, alle erreich-baren Festplatten an sich zu binden und in die eigene Hardwarekonfigurationeinzubinden.

Gerade Windows Server neigen dazu, alle sichtbaren Speicherressourcenzu beanspruchen. Bei einem Speichernetz kann es so vorkommen, dassSpeicherbereiche, die anderen Systemen zugeordnet sind, diesen entzogenwerden oder Daten darauf verfälscht oder zerstört werden.

Gefährdungskatalog Technisches Versagen G 4.13 Bemerkungen


G 4.13 Verlust gespeicherter Daten

Der Verlust gespeicherter Daten kann erhebliche Auswirkungen auf den IT-Einsatz haben. Sind die Anwendungsdaten oder die Kundenstammdaten ver-loren oder verfälscht, so können privatwirtschaftliche Betriebe in ihrer Existenzbedroht sein. Der Verlust oder die Verfälschung wichtiger Dateien kann in Be-hörden Verwaltungs- und Fachaufgaben verzögern oder sogar ausschließen.

Der Verlust gespeicherter Daten kann erhebliche Auswirkungen auf Ge-schäftsprozesse und damit auf die gesamte Institution haben. Wenn ge-schäftsrelevante Informationen, egal welcher Art, zerstört oder verfälscht wer-den, können dadurch Geschäftsprozesse und Fachaufgaben verzögert odersogar deren Ausführung verhindert werden. Insgesamt kann der Verlust ge-speicherter Daten, neben dem Produktionsausfall und den Kosten für die Wie-derbeschaffung der Daten, vor allem zu langfristigen Konsequenzen, wie Ver-trauenseinbußen bei Kunden und Partnern sowie einem negativen Eindruck inder Öffentlichkeit, führen. Von den durch Datenverluste verursachten direktenund indirekten Schäden können Institutionen sogar in ihrer Existenz bedrohtsein.

Dabei können die Gründe für den Verlust gespeicherter Daten vielfältiger Artsein:

- Entmagnetisierung von magnetischen Datenträgern durch Alterung oderdurch ungeeignete Umfeldbedingungen (Temperatur, Luftfeuchte),

- Störung magnetischer Datenträger durch äußere Magnetfelder,- Zerstörung von Datenträgern durch höhere Gewalt wie Feuer oder Was-

ser,- versehentliches Löschen oder Überschreiben von Dateien,- vorsätzliches oder versehentliches Setzen von Löschmarkierungen in Ar-

chivsystemen (siehe auch G 5.106 Unberechtigtes Überschreiben oderLöschen von Archivmedien),

- technisches Versagen von Peripheriespeichern (Headcrash),- fehlerhafte Datenträger,- unkontrollierte Veränderungen gespeicherter Daten (Integritätsverlust)

und- Datenzerstörung durch Schadprogramme.



G 4.53 Unsichere Default-Einstellungenbei Speicherkomponenten

Speicherkomponenten werden von Herstellern oft mit unsicheren Default-Kon-figurationen ausgeliefert, die den sicheren Einsatz gefährden.

Folgende Aspekte sind häufig problematisch:

Betriebssystem

Speichersysteme werden oft mit einem veralteten Versionsstand des Betrie-bssystems ausgeliefert. Dieser entspricht oft nicht dem aktuellen Sicherheits-stand.

Hostname

Voreingestellte Hostnamen verraten oft den Hersteller der Geräte. Dadurchkönnten gezielte Angriffe auf bekannte Sicherheitslücken dieser Geräte gest-artet werden.

Dienste

Werkseitig werden Geräte mit Standardkonfigurationen ausgeliefert, auf de-nen eine Vielzahl von Diensten aktiviert sind. Beispielsweise können diesHTTP, Telnet, FINGER oder sonstige Dienste sein, die aus Sicherheitsgrün-den bei Speichersystemen nicht aktiviert sein sollten.

Benutzerkonten und Passwörter

Vom Hersteller eingerichtete Benutzerkonten haben oft dokumentierte und da-mit allgemein bekannte Standardnamen und -passwörter. Auf einschlägigenInternet-Seiten stehen Listen mit herstellerspezifischen Standard-Accountsund Passwörtern zum Download bereit, so dass hierüber ein einfacher Zugriffauf die Systeme für Unbefugte möglich ist.

Unsichere SNMP-Versionen

Die Authentisierung erfolgt bei SNMPv1 und SNMPv2 lediglich mittels einesunverschlüsselten sogenannten Community Strings. Als Standardeinstellungbei nahezu allen Herstellern ist der Read-Community-String auf den Wert "pu-blic" eingestellt, während der Write-Community-String auf den Wert "private"gesetzt ist. Wenn die unsicheren SNMP-Versionen genutzt werden und fürdie Administration kein eigenes Administrationsnetz eingerichtet wurde, kannein Angreifer leicht die Kontrolle über Netzkomponenten erlangen, wenn dieseDefault-Einstellungen beibehalten werden.



G 4.95 Ausfall von Komponenten einerSpeicherlösung

Komplexe, netzbasierte Speicherlösungen bestehen in der Regel aus einerVielzahl von Komponenten. Ausfallpotenzial wird dabei vor allem in diesenTeilbereichen gesehen:

- FC-Switche- Virtualisierungs-Appliance- Storage Controller (Block, NAS, NAS-Gateway)- Leitungen- Datenträger

Der Ausfall von Komponenten einer Speicherlösung kann weitreichende Fol-gen für eine Institution haben. Im Anschluss an einen solchen Ausfall arbeitenunter Umständen wichtige Anwendungen nicht mehr korrekt, es drohen Da-tenverluste und finanzielle Risiken. Häufig ist bei einem Problem gar nicht so-fort ersichtlich, welche der oben genannten Komponenten ausgefallen ist unddas konkrete Problem mitverursacht hat. So kann ein eigentlich kleiner Ausfallzu größerer Ausfallzeit und erheblichen Aufwänden für die Fehlersuche undFehlerbeseitigung führen.



G 4.96 Fehlfunktion von Komponenteneiner Speicherlösung

Die Fehlfunktion von Komponenten einer Speicherlösung kann weitreichen-de Folgen für eine Institution haben. Im Anschluss an eine aufgetretene Fehl-funktion arbeiten unter Umständen wichtige Anwendungen nicht mehr korrekt,es drohen Datenverluste und finanzielle Risiken. Dies gilt beim Einsatz vonSpeicherlösungen für Cloud Services auch für die Fehlfunktion der Kommuni-kation zwischen dem sogenannten Cloud Orchestrator und dem Storage-Ele-ment-Manager.

Ursachen für solche Fehlfunktionen können unterschiedlicher Natur sein. Einhäufiger Grund liegt darin, dass nicht kompatible Systemkomponenten einge-setzt werden. Viele Hersteller setzen voraus, dass Institutionen sich beim Auf-bau und Betrieb komplexer IT-Infrastrukturen an die Kompatibilitätsmatrix derHersteller halten. Wird von diesem Vorgehen abgewichen, kann es zu einerFehlfunktion kommen oder die Leistung kann vermindert werden.

Verzeichnet eine Institution beispielsweise aufgrund von mangelndem Quali-ty of Service (QoS) Performanceeinbußen, wenn auf benötigte Speicherres-sourcen zugegriffen wird, ist dies ebenfalls als Fehlfunktion von Komponentenanzusehen.

Eine besondere Ausprägung der Fehlfunktion von Komponenten ist unterG 4.95 Ausfall von Komponenten einer Speicherlösung beschrieben.

Gefährdungskatalog Vorsätzliche Handlungen G 5.1 Bemerkungen


G 5.1 Manipulation oder Zerstörungvon Geräten oder Zubehör

Außentäter, aber auch Innentäter, können aus unterschiedlichen Beweggrün-den (Rache, Böswilligkeit, Frust) heraus versuchen, Geräte, Zubehör, Schrift-stücke und andere Datenträger zu manipulieren oder zu zerstören. Die Angrif-fe können umso wirkungsvoller sein, je später sie entdeckt werden, je umfas-sender die Kenntnisse des Täters sind und je tief greifender die Folgen füreinen Arbeitsvorgang sind. Die Manipulationen reichen von der unerlaubtenEinsichtnahme in schützenswerte Daten bis hin zur Zerstörung von Datenträ-gern oder IT-Systemen. Erhebliche Ausfallzeiten können die Folge sein.

Beispiel:

- In einem Unternehmen nutzte ein Innentäter seine Kenntnis darüber, dassein wichtiger Server empfindlich auf zu hohe Betriebstemperaturen rea-giert, und blockierte die Lüftungsschlitze für den Netzteillüfter mit einemhinter dem Server versteckt aufgestellten Gegenstand. Zwei Tage spätererlitt die Festplatte im Server einen temperaturbedingten Defekt und derServer fiel für mehrere Tage aus. Hinterher behauptete der Angreifer, dasses sich um ein Versehen gehandelt habe.

- Ein Mitarbeiter hatte sich über das wiederholte Abstürzen des Systems sostark geärgert, dass er seine Wut an seinem Arbeitsplatzrechner ausließ.Er trat mehrmals gegen den Rechner und beschädigte dabei die Festplatteso stark, dass sie unbrauchbar wurde. Die darauf gespeicherten Datenkonnte die IT-Abteilung nur teilweise wieder durch ein Backup vom Vortagrekonstruieren.



G 5.2 Manipulation an Informationenoder Software

Informationen oder Software können auf vielfältige Weise manipuliert werden:durch falsches Erfassen von Daten, Änderungen von Zugriffsrechten, inhaltli-che Änderung von Abrechnungsdaten oder von Schriftverkehr, Änderungen inder Betriebssystem-Software und vieles mehr. Grundsätzlich betrifft dies nichtnur digitale Informationen, sondern beispielsweise auch Dokumente in Papier-form. Ein Täter kann allerdings nur die Informationen und Software-Kompo-nenten manipulieren, auf die er Zugriff hat. Je mehr Zugriffsrechte eine Personauf Dateien und Verzeichnisse von IT-Systemen besitzt bzw. je mehr Zugriffs-möglichkeiten auf Informationen sie hat, desto schwerwiegendere Manipula-tionen kann sie vornehmen. Falls die Manipulationen nicht frühzeitig erkanntwerden, kann der reibungslose Ablauf von Geschäftsprozessen und Fachauf-gaben dadurch empfindlich gestört werden.

Die Beweggründe der Täter sind vielfältig und reichen von Rache und mutwilli-ger Zerstörungslust bis zu Bereicherung oder anderen persönlichen Vorteilen.

Beispiele:- In einem Schweizer Finanzunternehmen wurde durch einen Mitarbeiter die

Einsatzsoftware für bestimmte Finanzdienstleistungen manipuliert. Damitwar es ihm möglich, sich illegal größere Geldbeträge zu verschaffen.

- Mitarbeiter, die die Firma verlassen, kopieren vorher Kundendaten, um siefür andere Zwecke gewinnbringend einzusetzen. Solche illegal beschaff-ten Daten von Privatkunden sind beispielsweise benutzt worden, um Ver-tragsabschlüsse vorzutäuschen. Mitarbeiter, die im Unfrieden eine Behör-de oder ein Unternehmen verlassen, könnten auch Informationen oder IT-Systeme mutwillig zerstören oder den Zugriff auf wichtige Informationenoder IT-Systeme verhindern.

- Manipulationen archivierter Dokumente können besonders schwer wie-gen, da sie unter Umständen erst nach Jahren bemerkt werden und eineÜberprüfung dann oft nicht mehr möglich ist. Archivierte Dokumente stel-len meist besonders schützenswerte Informationen dar. Die Manipulationsolcher Dokumente ist besonders schwerwiegend, da sie unter Umstän-den erst nach Jahren bemerkt wird und eine Überprüfung dann oft nichtmehr möglich ist.

- Eine Mitarbeiterin hat sich über die Beförderung ihrer Zimmergenossin inder Buchhaltung dermaßen geärgert, dass sie sich während einer kurzenAbwesenheit der Kollegin unerlaubt Zugang zu deren Rechner verschaffthat. Hier hat sie durch einige Zahlenänderungen in der Monatsbilanz enor-men negativen Einfluss auf das veröffentlichte Jahresergebnis des Unter-nehmens genommen.

- Ein Mitarbeiter ärgert sich darüber, dass sein Vorgesetzter ihm keine Ge-haltserhöhung bewilligt hat. Aus Wut sendet er an einige seiner Arbeits-kollegen per E-Mail ein Dokument, das einen Computer-Virus enthält undals Geschäftsbrief getarnt ist. Beim Öffnen dieses Dokuments werden un-terschiedliche Dateien auf den betroffenen Systemen verändert. Ein Mit-arbeiter ärgert sich darüber, dass sein Vorgesetzter ihm keine Gehalts-erhöhung gegeben hat. Aus Wut sendet er an einige seiner Arbeitskolle-gen per E-Mail ein Dokument, das einen Computer-Virus enthält und alsGeschäftsbrief getarnt ist. Beim Öffnen dieses Dokuments werden unter-schiedliche Dateien auf den betroffenen Systemen verändert.

- Ein Mitarbeiter empfindet die Einschränkungen durch Sicherheitsmaßnah-men bei seinem Smartphone als zu restriktiv und "rootet" sein Smartpho-ne. So gelangt nicht freigegebene Software auf das Gerät, die Schad-



software enthält, vertrauliche Informationen der Institution abgreift und anunbefugte Dritte verschickt. Dadurch entsteht ein großer wirtschaftlicherSchaden.



G 5.4 Diebstahl

Durch den Diebstahl von Datenträgern, IT-Systemen, Zubehör, Software oderDaten entstehen einerseits Kosten für die Wiederbeschaffung sowie für dieWiederherstellung eines arbeitsfähigen Zustandes, andererseits Verluste auf-grund mangelnder Verfügbarkeit. Darüber hinaus können Schäden durcheinen Vertraulichkeitsverlust und die daraus resultierenden Konsequenzenentstehen.

Gestohlen werden neben teuren IT-Systemen häufig auch mobile Endgerä-te, die unauffällig und leicht zu transportieren sind. Gerade neue Smartpho-nes oder Tablets sind bei Dieben als teure Statussymbole beliebt. Ihr Verlustist meist schwerwiegend, weil sie für viele Anwendungen benutzt werden (E-Mails, Internet, Präsentationen erstellen) und große Datenmengen speichernkönnen.

Beispiele:- Im Frühjahr 2000 verschwand ein Notebook aus dem amerikanischen

Außenministerium. In einer offiziellen Stellungnahme wurde nicht ausge-schlossen, dass das Gerät vertrauliche Informationen enthalten könnte.Ebenso wenig war bekannt, ob das Gerät kryptografisch oder durch ande-re Maßnahmen gegen unbefugten Zugriff gesichert war. Bei Sicherheits-untersuchungen war bereits vor ungenügenden Kontrollen gewarnt wor-den.

- In einem deutschen Bundesamt wurde mehrfach durch die gleichen unge-sicherten Fenster eingebrochen. Neben anderen Wertsachen verschwan-den auch mobile IT-Systeme. Das auch Akten kopiert oder manipuliertwurden, konnte nicht zweifelsfrei ausgeschlossen werden.

- In Großbritannien gab es eine Reihe von Datenpannen, bei denen vertrau-liche Unterlagen offengelegt wurden, weil Datenträger gestohlen wurden.In einem Fall wurden bei der britischen Luftwaffe Computer-Festplattengestohlen. Sie enthielten auch sehr persönliche Informationen, die zur Si-cherheitsüberprüfung von Mitarbeitern erfasst worden waren.

- Ein Mitarbeiter eines Call-Centers erstellte, kurz bevor er das Unterneh-men verlassen musste, Kopien einer großen Menge von vertraulichenKundendaten. Nach seinem Ausscheiden aus dem Unternehmen hat erdiese dann an Wettbewerber verkauft. Da anschließend Details hierüberan die Presse gelangten, verlor das Call-Center viele wichtige Kunden.



G 5.7 Abhören von Leitungen

Nicht nur wegen des geringen Entdeckungsrisikos ist das Abhören von Leitun-gen eine nicht zu vernachlässigende Gefährdung der Informationssicherheit.Grundsätzlich gibt es keine abhörsicheren Kabel. Lediglich der erforderlicheAufwand zum Abhören unterscheidet die Kabel. Ob eine Leitung tatsächlichabgehört wird, ist nur mit hohem messtechnischen Aufwand feststellbar.

Der Entschluss, eine Leitung abzuhören, wird für den Angreifer im Wesentli-chen durch die Frage bestimmt, ob die Informationen den technischen bzw.den finanziellen Aufwand und das Risiko der Entdeckung wert sind. Wie derAngreifer diese Frage beantwortet, ist sehr von seinen individuellen Möglich-keiten und Interessen abhängig. Somit ist es nicht möglich, sicher festzulegen,welche Informationen und damit Leitungen gegebenenfalls abgehört werdenkönnten.

Teilweise ist das Abhören von Leitungen mit sehr geringem Aufwand möglich.Bei manchen Arten der LAN-Verkabelung kann beispielsweise der Zugangzu einer LAN-Dose ausreichen, um den gesamten Netzverkehr des lokalenNetzes abzuhören. Hat der Angreifer Zugriff auf passive oder aktive Koppel-elemente des IT-Netzes, steigt das Angriffsrisiko erheblich. Besonders anfäl-lig gegenüber dem Abhören von Netzverkehr sind drahtlose Netze (WirelessLAN/Funk-LAN, IEEE 802.11), bei denen der Angreifer zudem ein nur sehrgeringes Entdeckungsrisiko eingeht.

Auch IT-Bereiche, die in der Regel als sicher angesehen werden, wie bei-spielsweise Speichernetze auf der Basis von Fibre-Channel-Verbindungen(FC-Verbindungen), unterliegen dem Risiko, abgehört zu werden. Die Vertrau-lichkeit von FC-Verbindungen wird dabei durch Einsatz sogenannter FC-Ana-lyser gefährdet.

Besonders kritisch ist die ungeschützte Übertragung von Authentisierungsda-ten bei Klartextprotokollen wie HTTP, FTP oder telnet, da sich hier die Po-sition der vom Benutzer eingegebenen Daten in den übertragenen Paketendurch die einfache Struktur der Protokolle leicht bestimmen lässt (siehe auchG 2.87 Verwendung unsicherer Protokolle in öffentlichen Netzen). Eine au-tomatische Analyse solcher Verbindungen lässt sich somit mit geringem Auf-wand realisieren.

Mittels Password-Sniffings können in einem ersten Schritt beispielsweisePasswörter bei der Übertragung zu einem System abgefangen werden. Dieserlaubt es dem Angreifer, anschließend auf das IT-System zu gelangen, umin der Folge lokal auf dem Rechner weitere Angriffe durchzuführen.

Beispiele:- Es ist falsch anzunehmen, dass per E-Mail versandte Nachrichten mit klas-

sischen Briefen vergleichbar sind. Da E-Mails während ihres gesamtenWeges durch das Netz gelesen werden können, ist ein Vergleich mit Post-karten sehr viel realistischer.

- Einige Hersteller liefern zusammen mit den Betriebssystemen Programme(Sniffer) aus, die zum Debuggen der Netze dienen, aber auch zum Abhö-ren benutzt werden können.



G 5.8 Manipulation von Leitungen

Neben dem Abhören von Leitungen (siehe G 5.7 Abhören von Leitungen) stel-len weitere bewusste Manipulationen oder gar die Zerstörung von IT-Leitun-gen eine Gefahr für die Institution dar. Vor allem die Primärverkabelung grö-ßerer Institutionen und Leitungen, welche die IT- oder TK-Anbindungen aneinen Provider realisieren, haben oft einen hohen Schutzbedarf in Bezug aufdie Verfügbarkeit.

Fehlfunktionen von Leitungen können bewusst und in manipulativer Absichtherbeigeführt werden. Möglich ist dies beispielsweise durch:

- Vorsätzliches falsches Patchen von Kabeln oder Verbindungen- Vorsätzliches falsches Stecken von Kabeln- Bewusst herbeigeführte Fehlbedienung bzw. Zerstörung von Kabeln- Bewusst herbeigeführte Verletzung vorgegebener Biegeradien bei Glas-

faserkabeln- Bewusste Verunreinigung von Steckverbindungen (z. B. optische Übertra-

gungsmedien, Fibre Channel)

Solche Manipulationen verfolgen oftmals das Ziel, den IT-Betrieb zu störenoder finanzielle Schäden für die Institution zu verursachen.

Beispiel:- Bei Ausbauarbeiten auf dem Gelände eines großen Unternehmens gelang

es Angreifern, im schlecht zutrittsgeschützten Baustellenbereich einen Re-visionsschacht zu öffnen. Mit einer Astschere wurde ein Glasfaserbündelder Primärverkabelung zerschnitten. Da damit einige Produktionsgebäudevom IT-Netz abgeschnitten waren, war der Betrieb gestört und teilweiseunterbrochen, was einen Schaden in Millionenhöhe verursachte.



G 5.10 Missbrauch vonFernwartungszugängen

Fernwartungszugänge ermöglichen es, von außen auf IT-Systeme zuzugrei-fen. Bei unzureichend gesicherten Fernwartungszugängen ist es denkbar,dass Unbefugte unbemerkt Zugang zu diesen IT-Systemen erlangen, unterUmständen sogar mit administrativen Berechtigungen. Beispielsweise könn-ten Angreifer nach Überwindung von Authentisierungsmechanismen wie derPassworteingabe alle Administrationstätigkeiten ausüben. Bei einem vollstän-digen Anlagenausfall, schweren Betriebsstörungen, verfälschten Daten oderauch dem Verlust der Vertraulichkeit aller auf dem betroffenen IT-System ge-speicherten Daten, können unter Umständen große finanzielle Schäden ent-stehen.

Beispiele:- Zur Weitergabe von Systemfehlern an den Hersteller wird bei Großrech-

nern mit dem Betriebssystem z/OS in der Regel das Remote Support Fa-cility (RSF) eingesetzt. RSF kann auch verwendet werden, um seitensdes Herstellers Patches am sogenannten Microcode vorzunehmen. EinMissbrauch des RSF-Zugangs von z/OS-Systemen stellt deshalb eine er-hebliche Gefahr dar.

- Weil die Passwort-Richtlinie mangelhaft durchgesetzt wurde beziehungs-weise weil die Passwort-Richtlinie zu schwach war, konnte das Passwortfür einen Wartungs-PC einer TK-Anlage durch systematisches Ausprobie-ren (durch eine Wörterbuchattacke) ermittelt werden. Nach Überwindungdes Anlagenpasswortes konnte der Angreifer die TK-Anlage nach eigenenVorstellungen administrieren.



G 5.18 Systematisches Ausprobierenvon Passwörtern

Zu einfache Passwörter lassen sich durch systematisches Ausprobieren her-ausfinden. Dabei ist zwischen dem simplen Ausprobieren aller möglichen Zei-chenkombinationen bis zu einer bestimmten Länge (sogenannter Brute-For-ce-Angriff) und dem Ausprobieren anhand einer Liste mit Zeichenkombinatio-nen (sogenannter Wörterbuch-Angriff) zu unterscheiden. Beide Ansätze las-sen sich auch kombinieren.

Die meisten Betriebssysteme verfügen über eine Datei oder Datenbank (z. B.passwd- bzw. shadow-Datei bei Unix oder RACF-Datenbank bei z/OS) mit denKennungen und Passwörtern der Benutzer. Allerdings werden zumindest diePasswörter bei vielen Betriebssystemen nicht im Klartext gespeichert, sondernes kommen kryptographische Mechanismen zum Einsatz. Ist die Datei nurunzureichend gegen unbefugten Zugriff geschützt, kann ein Angreifer dieseDatei möglicherweise kopieren und mit Hilfe leistungsfähigerer Rechner undohne Einschränkungen hinsichtlich der Zugriffszeit einem Brute-Force-Angriffaussetzen.

Die Zeit, die bei einem Brute-Force-Angriff zum Herausfinden eines Passwortsbenötigt wird, hängt ab von

- der Dauer einer einzelnen Passwortprüfung,- der Länge des Passworts und- der Zeichenzusammensetzung des Passworts (z. B. Buchstaben/Zahlen).

Die Dauer einer einzelnen Passwortprüfung hängt stark vom jeweiligen Sy-stem und dessen Verarbeitungs- bzw. Übertragungsgeschwindigkeit ab. ImFalle eines Angriffs spielen auch die Methode und die Technik des Angreiferseine Rolle.

Länge und Zeichenzusammensetzung des Passworts lassen sich dagegendurch organisatorische Vorgaben oder sogar durch technische Maßnahmenbeeinflussen.

Beispiel:- Mit einem gut ausgestatteten PC lassen sich derzeit bei der

Standard-Passwort-Verschlüsselung von Unix bzw. Linux etwa400.000 Passwortprüfungen pro Sekunde durchführen. Bei der Stan-dard-Passwort-Verschlüsselung von Windows NT/2000/XP sind es sogarüber 6.000.000 Prüfungen pro Sekunde (Quelle: Der Hamburgische Da-tenschutzbeauftragte, 2003). Bei einem Zeichenvorrat von 26 Zeichendauert es somit etwa 6 Tage, um ein 8 Zeichen langes Passwort unterUnix bzw. Linux zu ermitteln (Standard-Passwort-Verschlüsselung). Diegleiche Aufgabe dauert unter Windows sogar nur etwa 9 Stunden.



G 5.20 Missbrauch vonAdministratorrechten

Eine missbräuchliche Administration liegt vor, wenn man vorsätzlich recht-oder unrechtmäßig erworbene Super-User- (root-) Privilegien ausnutzt, umdem System oder dessen Benutzern zu schaden.

Beispiele:- Da root auf Unix-Anlagen keinerlei Beschränkungen unterliegt, kann der

Administrator unabhängig von Zugriffsrechten jede Datei lesen, verändernoder löschen. Außerdem kann er die Identität jedes Benutzers seines Sy-stems annehmen, ohne dass dies von einem anderen Benutzer bemerktwird, es ist ihm also z. B. möglich, unter fremden Namen Mails zu ver-schicken oder fremde Mails zu lesen und zu löschen.

- Es gibt verschiedene Möglichkeiten, missbräuchlich Super-User-Privilegi-en auszunutzen. Dazu gehören der Missbrauch von falsch administrier-ten Super-User-Dateien (Dateien mit Eigentümer root und gesetztem s-Bit) und des Befehls su.

- Die Gefährdung kann auch durch automatisches Mounten von austausch-baren Datenträgern entstehen: Sobald das Medium in das Laufwerk gelegtwird, wird es gemountet. Dann hat jeder Zugriff auf die dortigen Dateien.Mit sich auf dem gemounteten Laufwerk befindenden s-Bit-Programmenkann jeder Benutzer Super-User-Rechte erlangen.

- In Abhängigkeit von der Unix-Variante und der zugrunde liegenden Hard-ware kann bei Zugangsmöglichkeit zur Konsole der Monitor-Modus akti-viert oder in den Single-User-Modus gebootet werden. Das ermöglicht dieManipulation der Konfiguration.

- Durch Softwarefehler kann es möglich sein, dass eine Anwendung nur ei-ne begrenzt große Menge an Daten verarbeiten kann. Werden dieser An-wendung übergroße Datenmengen oder Parameter übergeben, könnenBereiche im Hauptspeicher mit fremdem Code überschrieben werden. Da-durch können Befehle mit den Rechten der Anwendung ausgeführt wer-den. Dies war unter anderem mit dem Befehl eject unter SunOS 5.5 mög-lich, der mit SetUID-Rechten ausgestattet ist, also bei der Ausführung Su-per-User-Rechte besitzt.



G 5.28 Verhinderung von Diensten

Ein solcher Angriff, auch "Denial of Service" genannt, zielt darauf ab, die Be-nutzer daran zu hindern, Funktionen oder Geräte zu verwenden, die ihnennormalerweise zur Verfügung stehen. Dieser Angriff steht häufig im Zusam-menhang mit verteilten Ressourcen, indem ein Angreifer diese Ressourcen sostark in Anspruch nimmt, dass andere Benutzer an der Arbeit gehindert wer-den. Es können zum Beispiel die folgenden Ressourcen künstlich verknapptwerden: Prozesse, CPU-Zeit, Plattenplatz, Inodes, Verzeichnisse.

Dies kann zum Beispiel geschehen durch:

- das Starten von beliebig vielen Programmen gleichzeitig,- das mehrfache Starten von Programmen, die viel CPU-Zeit verbrauchen,- das Belegen aller freien Inodes in einem Unix-System, sodass keine neuen

Dateien mehr angelegt werden können,- unkoordiniertes Belegen von Bandstationen in z/OS-Systemen, sodass

Anwendungen auf freie Bandstationen warten müssen und die Online-Ver-arbeitung eingeschränkt ist,

- bewusste Falscheingabe von Passwörtern (auch Skript-gesteuert) mitdem Ziel der Sperrung aller Kennungen eines z/OS-Systems,

- das Versenden bestimmter konstruierter Datenpakete, die beim Empfän-ger aufgrund von Software-Schwachstellen zu Fehlfunktionen oder zu ei-ner Überlastung führen können (zum Beispiel indem exzessiv kryptogra-phische Operationen aufgerufen werden),

- die gezielte Überlastung des Netzes,- das Kappen von Netzverbindungen- das gezielte Generieren von XML-Nachrichten mit großen Datenmengen,

rekursiven Inhalten, einer großen Anzahl an Verschachtelungen und feh-lerhaften DTDs, sodass ein XML-Parser intensiv Speicherressourcen sei-nes Systems belegt.



G 5.57 Netzanalysetools

Werden die im Netzsegment übertragenen Informationen nicht verschlüsselt,so können diese Informationen mithilfe von Netzanalysetools, sogenannten"Sniffern", im Klartext ausgelesen werden.

Moderne Managementwerkzeuge beinhalten heutzutage Funktionen, mit de-ren Hilfe Datenpakete gelesen werden können, um Probleme in Netzen zuanalysieren. Angreifer können diese Zusatzfunktionen missbrauchen, um ver-trauliche Daten auszulesen. Neben IP-Netzen sind auch Fibre-Channel-Ver-bindungen durch Netzanalysetools gefährdet. Unterschiedliche Hersteller bie-ten mittlerweile freien Zugang zu physischen FC-Analysern an, mit deren Hil-fe Datenverkehr mitgelesen werden kann. So können die gespeicherten Da-ten aus Speichernetzen abgegriffen werden, ohne dass auf die physischenDatenträger zugegriffen werden muss. An einem nicht gesicherten zentralenKnotenpunkt eingesetzt, entsteht hieraus ein enormes Risiko, die Vertraulich-keit der Daten zu gefährden.

Eine zusätzliche Gefährdung durch den Einsatz von Netzanalysetools stelltder Zugriff von Serviceprovidern auf angemietete Leitungen dar.



G 5.89 Hijacking von Netz-Verbindungen

Weitaus kritischer als das Abhören einer Verbindung ist das Übernehmen ei-ner Verbindung. Hierbei werden Pakete in das Netz eingeschleust, die denClient entweder blockieren oder umleiten. Der Serverprozess kann daraufhinnicht erkennen, dass ein anderes Programm an die Stelle des Original-Clientsgetreten ist. Bei dieser Übernahme einer bestehenden Verbindung kann derAngreifer nach erfolgreicher Authentisierung einer berechtigten Person belie-bige Aktionen in deren Namen ausüben.



G 5.102 Sabotage

Sabotage bezeichnet die mutwillige Manipulation oder Beschädigung von Sa-chen mit dem Ziel, dem Opfer Schaden zuzufügen. Besonders attraktive Zie-le können Rechenzentren oder Kommunikationsanbindungen von Behördenbzw. Unternehmen sein, da hier mit relativ geringen Mitteln eine große Wir-kung erzielt werden kann.

Die komplexe Infrastruktur eines Rechenzentrums kann durch gezielte Be-einflussung wichtiger Komponenten, gegebenenfalls durch Täter von außen,vor allem aber durch Innentäter, punktuell manipuliert werden, um Betriebs-störungen hervorzurufen. Besonders bedroht sind hierbei nicht ausreichendgeschützte gebäudetechnische oder kommunikationstechnische Infrastruktursowie zentrale Versorgungspunkte, die organisatorisch oder technisch gege-benenfalls auch nicht überwacht werden und für Externe leicht und unbeob-achtet zugänglich sind.

Beispiele:- In einem großen Rechenzentrum führte die Manipulation an der USV zu

einem vorübergehenden Totalausfall. Der Täter, er wurde ermittelt, hattewiederholt die USV von Hand auf Bypass geschaltet und dann die Haupt-stromversorgung des Gebäudes manipuliert. Der Totalausfall - insgesamtfanden in drei Jahren vier Ausfälle statt - führte partiell sogar zweimal zuHardware-Schäden. Die Betriebsunterbrechungen dauerten zwischen 40und 130 Minuten.

- Innerhalb eines Rechenzentrums sind auch sanitäre Einrichtungen un-tergebracht. Durch Verstopfen der Abflüsse und gleichzeitiges Öffnender Wasserzufuhr entstehen durch Wassereinbruch in zentralen Technik-komponenten Schäden, die zu Betriebsunterbrechungen des Produktivsy-stems führen.

- Für elektronische Archive stellt Sabotage ein besonderes Risiko dar, dahier meist auf kleinem Raum viele schützenswerte Dokumente verwahrtwerden. Dadurch kann unter Umständen durch gezielte, wenig aufwendi-ge Manipulationen ein großer Schaden verursacht werden.



G 5.129 Manipulation von Daten überdas Speichersystem

Über eine mangelhaft konfigurierte SAN-Installation kann eine ungewollte Ver-bindung zwischen Netzen entstehen. Eine gravierende Gefährdung für inter-ne Daten einer Institution kann z. B. entstehen, wenn ein Server mit SAN-An-schluss aus dem Internet erreichbar ist und so von außen kompromittiert wird.

Die Anbindung eines an das Speichersystem angeschlossenen Servers, dernicht genügend vom Internet abgeschottet ist, kann bei einer Kompromittie-rung des Servers auch zur Kompromittierung des Speichersystems führen. Sokönnen gegebenenfalls Daten im SAN, die anderen Maschinen zugeordnetsind, gelesen oder verändert werden.

Da so alle Sicherheits- und Überwachungsmaßnahmen wie Firewalls oderIDS (Intrusion Detection Systeme) in den IT-Netzen der Institution übergangenwerden, ist das Schadenspotential sehr groß.



G 5.130 Manipulation der Konfigurationeiner Speicherlösung

Zentrale Speicherlösungen konzentrieren eine Vielzahl wichtiger Daten einerInstitution. Für sie ergeben sich daher in der Regel besondere Sicherheitsan-forderungen, denen im Rahmen einer sorgfältigen Konfiguration Rechnung zutragen ist.

Wenn es einem Angreifer gelingt, an Passwörter zu gelangen, die den Zugriffauf Konfigurationsprogramme (Element Manager) der Speicherlösung erlau-ben, kann er eine Vielzahl von Sicherheits- und Kontrollmaßnahmen umge-hen.

Fehlt in einem solchen Fall ein Rechte- und Rollenkonzept oder ist dies nurunzureichend umgesetzt, bieten sich dem Angreifer Möglichkeiten, die Konfi-guration der Speicherlösung zu verändern. Nachfolgend ist beschrieben, wiesich die Manipulation an bestimmten Konfigurationsparametern auswirkt.

- Die Konfigurationsveränderungen betreffen die Einstellungen des Zo-nings. In der Folge ist es möglich, zusätzliche Komponenten im FC-Netzanzumelden, die ursprünglich nicht über die benötigten Zugriffsrechte ver-fügten.

- Manipuliert ein Angreifer die Konfiguration des Zonings, ist es ihm mög-lich, die Zugriffswege zwischen Servern und Speicherressourcen zu ver-ändern. Damit kann er unberechtigt auf Informationen zugreifen bzw. dieZugriffsrechte für andere Benutzer einschränken.

- Manipuliert ein Angreifer die LUN-Konfiguration, ist es ihm möglich, aufSpeicherressourcen zuzugreifen, die für ihn im Vorfeld nicht verfügbar wa-ren.

- WWN-Spoofing (siehe hierzu G 5.186 Zugriff auf Informationen andererMandanten durch WWN-Spoofing)

In der Folge unberechtigter Manipulationen und Konfigurationsänderungenkann nicht mehr gewährleistet werden, dass die Sicherheitsanforderungenan die Speicherlösung eingehalten werden. Unberechtigte Zugriffe auf Spei-cherressourcen oder die Manipulation von Daten sind möglich.



G 5.185 Erlangung physischen Zugangsauf SAN-Switches

Existieren in einer Institution unzureichende Zugangskontrollen zu den Kom-ponenten einer Speicherlösung oder fehlen diese gänzlich, ist es einem An-greifer möglich, sich physischen Zugang zu vorhandenen Switches zu ver-schaffen bzw. zusätzliche FC-SAN-Switches an das Netz anzuschließen.

Hinter einem solchen Angriff verbergen sich möglicherweise folgende Absich-ten, die eine Gefährdung für die Institution darstellen:

- Ziel eines Zugangs könnte es sein, dem Angreifer zu gestatten, auf dieverteilte Zoning-Datenbank zuzugreifen, um diese so zu verändern, dasser auf die Speichersysteme zugreifen kann.

- Zusätzliche FC-SAN-Switches werden in den Datenstrom eingeschliffen,um Daten mitzuschneiden, beispielsweise indem das FC-Routing verän-dert wird.

- Die Name Server Database wird dahingehend verändert, dass sich einAngreifer als Zielsystem darstellt und damit die Daten der Initiatoren ab-fangen kann.

- WWN-Spoofing als Basis für die Durchführung weiterer Angriffe (siehez. B. G 5.186 Zugriff auf Informationen anderer Mandanten durch WWN-Spoofing)

Der physische Zugang zu Komponenten der Speicherlösung kann darüberhinaus auch mit der Absicht erfolgen, einen Denial-of-Service-Angriff (DoS)durchzuführen. Dem Angreifer stehen hierzu unterschiedliche Varianten derManipulation zur Verfügung:

- Ausschalten einzelner Komponenten- Umstecken oder Entfernen gesteckter Kabel- Verletzen der Biegeradien von Kabeln, um den Datentransfer zu stören

oder die Datenübertragung komplett zu verhindern- Senden von Reconfigure-Fabric-Nachrichten (RCF), um den normalen

Datenverkehr zu stören



G 5.186 Zugriff auf Informationenanderer Mandanten durch WWN-Spoofing

Mittels Programmen, die durch den Hersteller des Host Bus Adapters (HBA)zur Verfügung gestellt werden, kann der World Wide Name (WWN) einesHBAs geändert werden. Der Angreifer kann somit auf Daten zugreifen, fürderen Einsicht er keine Berechtigung besitzt. Die Kenntnis der WWN der zuspoofenden HBA erleichtert einen solchen Angriff, jedoch besteht für Angrei-fer auch die Möglichkeit, diese auf andere Weise zu ermitteln. Einen einfachzu ermittelnden Teil der WWN stellt der Object Identifier (OID) des jeweiligenHerstellers dar. Sofern die HBAs aus einer Produktionscharge stammen, lie-gen die WWNs mit großer Wahrscheinlichkeit dicht zusammen. Mittels Bru-te-Force-Attake kann daher die WWN komplettiert werden.

Die Manipulation von WWNs, auch als WWN-Spoofing bezeichnet, birgt füreine Institution erhebliches Gefahrenpotenzial. Insbesondere im Zusammen-hang mit mandantenfähigen Speicherlösungen können unberechtigte Zugriffeauf Informationen anderer Mandanten die Folge solcher Angriffe sein.

Mögliche Ausprägungen von Angriffen durch WWN-Spoofing sind:

- Ein fehlendes oder unzureichendes Rechte- und Rollenkonzept ermöglichtden administrativen Zugriff auf Werkzeuge zur Manipulation der WWN aufdem HBA.

- Bei Einsatz von WWN-Zoning ermöglicht WWN-Spoofing unberechtigtenZugriff auf Netzressourcen.

- Bei Einsatz von Port-Zoning ermöglicht ein physischer Zugang zum Switchden Anschluss von Komponenten an entsprechende Ports. Durch diesenAngriff können alle Informationen in der betroffenen WWN durch den An-greifer manipuliert werden.

- Die Manipulation des LUN-Maskings mittels WWN-Spoofing führt dazu,dass Systeme auf Speicherressourcen zugreifen können, für die sie ur-sprünglich nicht berechtigt waren.



G 5.187 Überwindung der logischenNetzseparierung

Erfolgt die Trennung von Netzstrukturen unterschiedlicher Mandanten nichtdurch den Aufbau physisch getrennter Netze, sondern kommen hierfür virtu-elle Storage Area Networks (VSANs) oder Local Area Networks (VLANs) zumEinsatz, kann dies unter Umständen zu einer Gefährdung für die Informations-sicherheit der Institution führen.

Gelingt es einem Angreifer, beispielsweise durch Ausnutzen von Schwach-stellen, in das Netz eines anderen Mandanten einzudringen, kann er auf die-sem Weg sowohl administrativen Zugriff auf das SAN oder LAN dieses Man-danten erlangen als auch auf die übertragenen Nutzdaten. Fehlende oder un-zureichende Rechte-, Rollen- sowie Zonenkonzepte erhöhen dabei das Scha-denspotenzial solcher Angriffe.

Grundsätzlich ist die Überwindung der Separierung über mehrere Wege mög-lich (siehe hierzu auch G 5.115 Überwindung der Grenzen zwischen VLANs):

- Der Angreifer erlangt physischen Zugriff auf einen Switch und kann diesenmanipulieren.

- Der Angreifer nutzt eine vorhandene Fehlkonfiguration aus. Hierbei kannzum einen die Mandantenfähigkeit falsch konfiguriert worden sein, sodassder Angreifer Zugriff auf andere Mandanten erhält. Zum anderen kanndie eigentliche Zuordnung eines Anwenders zu einem virtuellen SAN oderLAN falsch vorgenommen worden sein. Der Angreifer erhält daraufhin Zu-griff auf Daten innerhalb eines virtuellen Netzes, für die er ursprünglichkeine Berechtigung besitzt.

- Der Angreifer nutzt eine ungepatchte Software-Schwachstelle aus.

N-Port ID Virtualization (NPIV) wird in virtuellen Storage Area Networks(VSAN) eingesetzt, bei denen der physische SAN-Server über eine unzurei-chende Anzahl an Fibre-Channel-Ports verfügt. NPIV erlaubt einem physi-schen Host Bus Adapter Port, mit mehreren World Wide Port Name (WWPN)verknüpft zu werden. Der Einsatz von NPIV in Fibre-Channel-Netzen kanndazu führen, dass ein Server sich durch Nutzung des gleichen WWPN unbe-rechtigt Zugriff auf Daten eines anderen Servers verschaffen kann.



G 5.188 Unberechtigter Zugriff auf Dateninnerhalb einer Cloud-Storage-Lösung

Innerhalb einer Cloud-Storage-Lösung besteht die Gefahr unberechtigter Zu-griffe auf Daten anderer Mandanten durch ein fehlendes oder unzureichendesRechte- und Rollenkonzept sowie Zonenkonzept.

Wird bei Auswahl und Konfiguration der Komponenten einer Cloud-Stora-ge-Lösung nicht ausreichend auf die Möglichkeiten der Mandantenfähigkeitdes Speichersystems und der Netzkomponenten des Storage Area Networks(SAN) und Local Area Networks (LAN) geachtet, ermöglicht dies ebenfalls denunberechtigten Zugriff bzw. die Manipulation von Daten.



G 5.189 Verlust der Vertraulichkeitdurch storagebasierteReplikationsmethoden

Storagebasierte Replikationsmethoden haben ursprünglich den Zweck, ge-speicherte oder archivierte Daten in Echtzeit über ein Speichernetz zu dupli-zieren und damit zusätzliche Redundanzen zu erzeugen. Hierdurch wird demVerlust von Daten vorgebeugt.

Die automatisierte Replikation unverschlüsselter Daten birgt allerdings sowohlim eigenen Campus-Netz als auch bei der Nutzung öffentlicher NetzanbieterRisiken. Sowohl bei der IP-Replikation als auch bei der FC-Replikation könn-ten Angreifer möglicherweise Schwachstellen der storagebasierten Replikati-on ausnutzen, um unberechtigt auf die Daten zuzugreifen.

Zu unterscheiden sind grundsätzlich folgende Angriffsszenarien:

- Der unberechtigte Zugriff erfolgt auf legitimen Replikationsverkehr, bei-spielsweise mittels Einsatz von FC-Analysern (FC-Replikation) oder Snif-fern (IP-Replikation). Siehe dazu auch G 5.7 Abhören von Leitungen.

- Ein Angreifer initiiert eine nicht autorisierte Replikation mit einem durch ihnkontrollierten System als Ziel.

- Ein Angreifer verschafft sich Zugriff auf eine vorhandene Replikation, wenndiese nicht oder nur unzureichend geschützt ist.

Maßnahmenkatalog Infrastruktur M 1.59 Bemerkungen


M 1.59 Geeignete Aufstellung vonSpeicher- und Archivsystemen

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Administrator, Leiter IT

Da in Speicher- und Archivsystemen wichtige Behörden- bzw. Unternehmens-daten konzentriert aufbewahrt werden, müssen deren IT-Komponenten in ge-sicherten Räumen aufgestellt werden, zu denen nur Berechtigte Zutritt haben.Dies betrifft neben den eingesetzten Servern und Netzkomponenten insbeson-dere die Speichereinheiten (Plattenarrays, Bandlaufwerke, Disc-Jukeboxen).

Für die geeignete Aufstellung dieser IT-Komponenten sind alle relevantenMaßnahmen, die in den IT-Grundschutz-Katalogen zur Infrastruktur-Sicher-heit beschrieben sind, zu realisieren. Je nach Art und Größe des Speicher-oder Archivsystems sind die Bausteine B 2.1 Allgemeines Gebäude, B 2.9 Re-chenzentrum, B 2.4 Serverraum bzw. B 2.7 Schutzschränke heranzuziehen.Hierbei sollte besonders auf eine ausreichende Zuverlässigkeit der infrastruk-turellen Komponenten (Stromzufuhr, etc.) geachtet werden. Beim Einsatz vonSpeichersystemen sind zudem angemessene Redundanzen in der techni-schen Infrastruktur zu schaffen (siehe M 1.52 Redundanz, Modularität undSkalierbarkeit in der technischen Infrastruktur), um die Verfügbarkeit dieserzentralen Ressourcen so gut wie möglich zu unterstützen.

Für die langfristige Aufbewahrung der verwendeten Archiv-Speichermediensind die in M 1.60 Geeignete Lagerung von Archivmedien genannten Lagerbe-dingungen einzuhalten. Vor allem die zweckmäßige Klimatisierung von Spei-chermedien, aber auch der Archivsysteme selbst, ist hier zu beachten.

Häufig werden elektronische Archive so realisiert, dass Archivmedien im dau-erhaften Zugriff durch die Speichereinheit gehalten werden. Hierzu kommenvielfach dedizierte Speichereinheiten zum Einsatz, die selbsttätig Wechsel-medien verwalten und einlegen können, beispielsweise Roboter für Bandlauf-werke oder Jukeboxen für Disc-Medien. Wenn ein Speicher- oder Archivsy-stem solche Komponenten beinhaltet, werden in der Regel die Archivmedi-en während ihrer gesamten Lebensdauer nicht mehr aus der Speichereinheitausgelagert. Das bedeutet, dass die an Archivmedien zu stellenden Lagerbe-dingungen (bezüglich Klimatisierung, Zugriffsschutz, etc.) bereits in der Spei-cherkomponente erfüllt und überwacht werden müssen.

Bei Auswahl des Speicher- oder Archivsystems ist daher als Kriterium zu be-rücksichtigen, dass die erforderlichen Lagerbedingungen für Archivmedien inSpeicherkomponenten eingehalten werden können bzw. welcher Zusatzauf-wand hierfür entsteht.

Prüffragen:

- Erfolgt die Aufstellung der IT-Komponenten in gesicherten Räumen?- Ist der Zutritt zu den Räumlichkeiten der IT-Komponenten nur

berechtigten Personen vorbehalten?- Ist die Zuverlässigkeit der infrastrukturellen Komponenten sichergestellt?- Bei Hochverfügbarkeit: Sind Redundanzen hinsichtlich der technischen

Infrastruktur gegeben?- Werden bei langfristiger Aufbewahrung die Lagerbedingungen der Archiv-

Speichermedien eingehalten?

Maßnahmenkatalog Organisation M 2.351 Bemerkungen


M 2.351 Planung von SpeicherlösungenVerantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-

SicherheitsbeauftragterVerantwortlich für Umsetzung: IT-Sicherheitsbeauftragter, Leiter IT

Die grundsätzliche Entscheidung, welche Art von Speicherlösung angemes-sen für die Institution ist, muss durch eine Anforderungsanalyse getroffen wer-den. Zunächst ist festzustellen, welche Anwendungen von der Speicherlösungzukünftig unterstützt werden sollen und welche vorhandene Hardware durcheine neue Speicherlösung unterstützt oder abgelöst werden soll.

Maßgebliche Kenngrößen sind die Anforderungen an Verfügbarkeit, Perfor-mance und Kapazität. Bei normalen Verfügbarkeitsanforderungen sollte zu-dem geprüft werden, welche Komplexität für die Institution tragbar ist. DieEinführung von SAN-Lösungen bedeutet, dass eine neue Basistechnik einge-führt wird. Damit ist ein entsprechender Aufwand zur Planung und Einführungdieser Technik zu kalkulieren. Beim geplanten Einsatz von Speicherlösungenin virtualisierten Serverumgebungen sind beispielsweise zusätzliche Aspektewie die Gewährleistung einer eineindeutigen WWN- oder Netzadressvergabezu beachten, deren Umsetzung zusätzlichen Aufwand generiert.

NAS-Lösungen sind besonders auf die einfache Integration in etablierte IT-Umgebungen und auf den dateiorientierten Zugriff ausgerichtet. Ihr Einsatzist daher dann angezeigt, wenn Dateien und dateiorientierte Anwendungenauf zentrale hochwertigere, aber dennoch eher einfach zu administrierendeSpeicherlösungen konsolidiert werden sollen.

Wenn kurzfristig Speicherplatz auf Servern durch zentralen Speicher ersetztwerden soll, langfristig jedoch höhere Verfügbarkeitsanforderungen zu erwar-ten sind, kann auch der Einsatz von Speicherlösungen erwogen werden, dieeine Mischform von SAN und NAS darstellen. Sogenannte Hybrid-Speicherlö-sungen lassen sich in erster Ausbaustufe als (sehr hochwertige) NAS-Lösun-gen betreiben. Durch Aufrüstung interner Komponenten können sie zu SAN-Lösungen für weitere Server und bei Bedarf zu redundanten Speichernetzenausgebaut werden.

Wenn die Schutzbedarfsfeststellung für eines dieser betrachteten Systemesofort oder in absehbarer Zukunft ergibt, dass hoher oder sogar sehr hoherSchutzbedarf in Bezug auf Verfügbarkeit vorliegt, sodass eine redundanteDatenspeicherung an verschiedenen Standorten erforderlich ist, dann sollteSAN-Technik eingesetzt werden. In diesem Fall sollte dringend darauf geach-tet werden, dass die Speicherlösung SAN-Protokolle unterstützt. Mit dieserTechnik lassen sich vollständig redundante und hochverfügbare Speicherlö-sungen aufbauen.

Die Entscheidung für den Einsatz einer bestimmten Speicherlösung, beispiels-weise NAS oder SAN, ist auf geeignete Weise zu dokumentieren. Innerhalbder Institution empfiehlt sich daher bereits im Verlauf der Planungs- und Kon-zeptionsphase einer Speicherlösung die Erstellung eines fachlichen Grobkon-zeptes. Dieses sollte alle Aspekte betrachten, die Gegenstand dieser Maß-nahme sind, also unter anderem die Anforderungen an die Speicherlösung,die Auswahl von Hardware und Lieferanten, Planung der Infrastruktur etc. Dar-über hinaus ist ein Sicherheitskonzept für den Einsatz von Speicherlösungenzu erstellen.



Es ist ebenfalls im Rahmen der Planung zu regeln, wie die aufzubauende Spei-cherlösung in die bestehenden Betriebsprozesse integriert werden kann. Aufdiesem Weg ist bereits zu einem frühen Zeitpunkt erkennbar, wie bestehen-de Prozesse angepasst und verändert werden müssen. Verzögerungen in derUmsetzungs- und Betriebsphase können damit vermieden oder zumindest re-duziert werden.

Sofern nicht bereits an einer übergeordneten Stelle erfolgt, sollte im Rahmender Planungsaktivitäten einer Speicherlösung auch festgehalten werden, wiemit der Versionierung eingesetzter Software zu verfahren ist. Dies verhindertspätere Verstöße gegen bestehende Kompatibilitätsmatrizen und bietet derInstitution bei Bekanntwerden von Schwachstellen oder kritischen Fehlern dieMöglichkeit, schnell zu erkennen, ob Handlungsbedarf besteht.

Auswahl der Hardware

Entscheidende Kenngrößen bei der Auswahl der Speicherlösung sind:

- der derzeitige und der prognostizierte Bedarf an Speicherplatz, der durchAnwendungen definiert wird (Kapazitätsanforderungen),

- die Anforderungen der Anwendungen an die Geschwindigkeit der Spei-cherzugriffe (Performanceanforderungen),

- die Anforderungen an die Ausfallsicherheit für die Anwendungen (Verfüg-barkeitsanforderungen),

- die Anforderungen an die Vertraulichkeit und Integrität der zu verarbeiten-den Daten als Entscheidungsgrundlage für den möglichen Einsatz hard-warenaher Verschlüsselungsmechanismen (Sicherheitsanforderungen)

- Möglichkeit zum Einsatz von Secure Operating Systemen. Solche speziel-len Betriebssysteme können die Komplexität von Sicherheitskonfiguratio-nen reduzieren und zudem dazu beitragen, den manuellen Verwaltungs-aufwand und die Fehlerwahrscheinlichkeit zu senken.

Es ist für die Planung von Speicherlösungen zu erfassen, welche Ge-schäftsprozesse und Anwendungen in der Institution die Speicherlösung so-fort und in Zukunft nutzen werden und welche Anforderungen bezüglich desWachstums des Speicherbedarfs, der Performance und der Ausfallsicherheitdadurch gestellt werden. Bei einer solchen Prognose sollte beachtet werden,dass eine solche Schätzung stets sehr großzügig erfolgen sollte. Es zeigt sichimmer wieder, dass auch großzügige Schätzungen des zukünftigen Speicher-bedarfs in kurzer Zeit von den tatsächlichen Anforderungen übertroffen wer-den.

Bei der Planung von Speicherlösungen muss auch die erforderliche Datensi-cherung mit einbezogen werden, denn die Abschätzung des Speicherbedarfsbestimmt auch, wie die Datensicherungsumgebung ausgelegt werden muss.Hierbei muss sichergestellt werden, dass auch nach Ausbau der Speicherlö-sung mit den angeschlossenen Datensicherungsgeräten die Zeiten für Daten-sicherung und auch für das Wiedereinspielen einer Datensicherung eingehal-ten werden können, die den Verfügbarkeitsanforderungen der betroffenen Or-ganisationseinheiten genügen.

Anforderung der Anwendungen

Speicherlösungen dienen üblicherweise einer Vielzahl von Servern und damitvon Anwendungen zur Speicherung ihrer Daten. Die Anforderungen an dieSpeicherlösung in Bezug auf Verfügbarkeit, Integrität und Vertraulichkeit wer-den durch die Anwendung mit dem höchsten Schutzbedarf definiert.



Bei der internen technischen Auslegung eines SANs ist zu prüfen, ob dieVerfügbarkeitsanforderungen der Institution an das SAN nahelegen, eine de-sastertolerante Auslegung (M 2.354 Einsatz einer hochverfügbaren SAN-Lö-sung) zumindest in die Planungen einzubeziehen.

Wenn die Institution Anwendungen betreibt, die besonders hohe Anforderun-gen an die Vertraulichkeit der Daten stellen, so ist in die Planungen einzu-beziehen, dass die Daten sowohl während des Transports im SAN als auchauf den Speichermedien durch Verschlüsselung geschützt werden. Dies ist imRahmen der ergänzenden Sicherheitsanalyse und Risikoanalyse zu betrach-ten.

Auswahl von Produkten/Herstellern/Lieferanten

Der Einsatz von Produkten verschiedener Generationen oder von verschiede-nen Herstellern erhöht im Allgemeinen die Komplexität des Gesamtsystemsund kann unter Umständen zu Problemen führen. Daher ist es ratsam, eineHomogenität der Systeme anzustreben. Auch bei der Auswahl der Vertrags-partner sollte berücksichtigt werden, dass Probleme, die beim Aufbau, Testund Betrieb entstehen können, in der Regel schneller und effektiver beseitigtwerden, wenn nur ein Anbieter involviert ist.

Auf der anderen Seite kann eine starke Abhängigkeit von bestimmten Herstel-lern oder Lieferanten auch Probleme verursachen. Meistens spielen außer-dem auch wirtschaftliche Aspekte bei der Auswahl der Produkte eine wichtigeRolle. Alle diese Faktoren sollten bei der Planung von Neubeschaffungen be-rücksichtigt werden. Als weiterer Punkt muss beachtet werden, dass Herstellermeistens die einwandfreie Funktion ihrer Lösungen nur für bestimmte Zusam-menstellungen von Hard- und Software garantieren und durch Supportleistun-gen unterstützen. Daher ist es ratsam, auf die Interoperabilitätszertifizierungder Hersteller im Hinblick auf die Einsatzumgebung ihrer Produkte und aufweitergehende verbindliche Aussagen zur Kompatibilität und Interoperabilitätvon Produkten zu achten. Oft veröffentlichen Hersteller in diesem Zusammen-hang sogenannte Kompatibilitätsmatrizen.

Hersteller von Speicherkomponenten erbringen Supportleistungen häufigauch über einen Fernwartungszugang. Bei der Auswahl eines Herstellers soll-ten die Vorgaben des Herstellers hinsichtlich erforderlicher Wartungsarbei-ten ermittelt werden. Ist eine Fernwartung vorgesehen, besteht für die In-stitution die Notwendigkeit zur Absicherung des Zugangs (M 5.33 Absiche-rung von Fernwartung). Insbesondere sollten die rechtlichen Randbedingun-gen des Landes beachtet werden, aus dem die Fernwartung erbracht wird, daes sein kann, dass Sicherheitsbehörden wie Nachrichtendienste die Zugangs-daten erhalten können, ohne dass dies dem SAN-Betreiber mitgeteilt wird. Beiweitergehenden Fragen zur Spionageabwehr sollte der Kontakt zu den Ver-fassungsschutzämtern des Bundes oder der Länder aufgenommen werden.

Einsatz zentraler Managementsysteme

Der Einsatz einer gemeinsamen Managementapplikation für die zentrale undeinfache Überwachung und Verwaltung von Ressourcen vereinfacht die Ad-ministration der Speicherlösung. Insbesondere für größere Speicherlösungenist der Einsatz eines zentralen Verwaltungssystems für eine effiziente Spei-cherverwaltung unumgänglich. Der Einsatz von proprietären Verwaltungsme-chanismen bei den verschiedenen Produkten machte es bisher schwierig, einzentrales Management in heterogenen Speicherumgebungen umzusetzen.



Die Verabschiedung des SMI-S (Storage Management Initiative Specification)Standards durch die SNIA (Storage Network Industry Association) bietet Her-stellern von Storagekomponenten die Möglichkeit, ihre Produkte auf einfacheWeise an zentrale Verwaltungssysteme anzubinden. Daneben bietet SMI-Seinen Weg, über heterogene Netze hinweg, Basisfunktionen wie beispielswei-se Storage-Provisionierung oder LUN Masking einzusetzen.

Die Version 1.6 von SMI-S beinhaltet zahlreiche Sicherheitsvorgaben, die sichhauptsächlich auf die Gewährleistung von Authentisierungsmechanismen unddie Sicherstellung der Vertraulichkeit beziehen. Die Betrachtung weiterer Si-cherheitsziele befindet sich in Entwicklung. Die SNIA stellt jeweils detailliertetechnische Dokumentationen aller bisherigen Versionen von SMI-S zur Ver-fügung.

Die SNIA stellt weiterhin Informationen darüber bereit, wie ein gewählter Her-steller SMI-S-konforme Hard- oder Software anbieten kann. Diese Angabensollten entsprechend bei der Planung der Speicherlösung berücksichtigt wer-den.

Bei der Planung des Einsatzes von SMI-S sollten mindestens folgende Sicher-heitsmechanismen für die Kommunikation zwischen Managementsystem undSpeicherlösung eingesetzt werden:

- Verschlüsselung: Einsatz sicherer Verschlüsselungsmechanismen zurvollständigen Verschlüsselung der Kommunikation (siehe MaßnahmeM 2.164 Auswahl eines geeigneten kryptographischen Verfahrens)

- Authentisierung: Empfohlen wird der Einsatz von HTTP Digest AccessAuthentication. HTTP Basic Authentication sollte nur eingesetzt werden,wenn die Authentisierung bereits über HTTPS oder eine andere Ver-schlüsselungsmethode geschützt wird.

Planung des Netzanschlusses

Die interne Vernetzung der SAN-Komponenten und die Anbindung an die Ser-ver erfolgen üblicherweise durch ein eigenes Fibre-Channel-Netz. Auch wenniSCSI genutzt wird, ist aus Gründen der Betriebssicherheit hierfür ein eigenesNetz aufzubauen.

Wenn zur Verwaltung und Kontrolle von NAS-Lösungen oder SAN-Kompo-nenten (Speichergeräte, SAN-Switches etc.) der Anschluss dieser Geräte anein LAN erforderlich ist, sollte dieses LAN als separates Administrationsnetzbetrieben werden. Damit werden folgende Schutzziele verfolgt:

- Administrative Daten und Aktionen können nicht von beliebigen Benutzernbelauscht werden.

- Es können Protokolle (insbesondere SNMP Version 1) eingesetzt werden,die bekannt unsicher sind, aber mangels verfügbarer Alternativlösungenzur Überwachung des Betriebs eingesetzt werden müssen.

- Die Rechteverwaltung innerhalb eines solchen Netzes wird übersichtli-cher.

- Besondere Kontrollmaßnahmen wie Intrusion-Detection-Systeme könnenübersichtlicher und effizienter gestaltet werden.

Der Einsatz unsicherer Protokolle sollte vermieden werden und stattdessenSNMP ab Version 3 eingesetzt werden. In der Praxis werden jedoch noch im-mer Systeme eingesetzt, die Version 3 nicht unterstützen und die daher aufältere Protokollversionen angewiesen sind. In diesem Fall entstehen zusätz-liche Risiken, denen sich die Verantwortlichen bewusst sein müssen. Dieseunsicheren Protokolle sollten nur innerhalb eines separaten abgeschottetenAdministrationsnetzes eingesetzt werden. Dies sollte aber höchstens eine mit-



telfristige Übergangslösung darstellen, langfristig sollten nur noch Geräte ein-gesetzt werden, die SNMP-Protokolle ab Version 3 unterstützen.

Infrastruktur

Bevor ein SAN angeschafft und in Betrieb genommen wird, müssen verschie-dene infrastrukturelle Aspekte in die Planungsmaßnahmen mit aufgenommenwerden.

Der Standort der Komponenten eines SANs muss in einem zutrittsgeschütztenServerraum oder einem Rechenzentrum geplant werden. Empfehlungen fürdie Infrastruktursicherheit von Serverräumen finden sich in Baustein B 2.4 Ser-verraum, die Anforderungen an Rechenzentren in Baustein B 2.9 Rechenzen-trum.

Neben der allgemein geschützten Aufstellung sollte auch überprüft werden,ob die Klimatisierung des gewählten Standorts und die Stromversorgung dortden technischen Anforderungen und der angestrebten Verfügbarkeit der Spei-cherlösung entsprechen. Die Stationierung der einzelnen Komponenten desSAN-Systems ist sorgfältig zu planen. So sollte sorgfältig geprüft werden, woSicherungsgeräte, die regelmäßige oder gelegentliche manuelle Eingriffe er-fordern (z. B. Entnahme oder Wechsel von Bandkassetten) zweckmäßig undunter Beachtung aller Sicherheitsanforderungen aufgestellt werden können.

Ebenso ist bei räumlich verteilten SAN-Konfigurationen zu prüfen, ob alle Ge-räte permanent mit Strom versorgt werden können. Es kann nötig sein, einenSAN-Switch in einem normalen Verteilerraum zu installieren, um extern sta-tionierte Server anzuschließen. Dieser Raum ist dann, ebenso wie die Ser-ver, in die Energieversorgung über USV und Netzersatzanlage einzubinden.Weitere Maßnahmen zur Notfallvorsorge bei SAN finden sich in MaßnahmeM 6.98 Notfallvorsorge und Notfallreaktion für Speicherlösungen.

Prozesse

Die Speicherlösung ist als zentrale IT-Komponente in alle Steuerungsprozes-se der IT zu integrieren. Insbesondere Überwachungs- und Eskalationsver-fahren sind innerhalb der vorhandenen Betriebsabläufe auf den NAS- oderSAN-Betrieb anzupassen. Leistungen des Herstellers zur Überwachung undBetriebssicherung sind in eigene Abläufe einzubeziehen. Dabei sind stets dieVorgaben der Sicherheitsleitlinie und weiterer Ausführungsbestimmungen derInstitution zu beachten.

Personal

Es ist zu überprüfen, wie viele Mitarbeiter mit welcher Ausbildung für den Be-trieb der Speicherlösung benötigt werden. Stehen nicht genügend ausgebilde-te Mitarbeiter zur Verfügung, müssen die erforderlichen Schulungsmaßnah-men rechtzeitig initiiert werden.

Prüffragen:

- Wurde eine Anforderungsanalyse zur Ermittlung der derzeitigen undzukünftigen Anforderungen an Verfügbarkeit, Performance und Kapazitätdurchgeführt?

- Wurde die Entscheidung für den Einsatz einer bestimmtenSpeicherlösung, beispielsweise NAS oder SAN, auf geeignete Weisedokumentiert?

- Wurde ein Sicherheitskonzept für den Einsatz von Speicherlösungenerstellt?



- Wurde die Infrastruktur für die Aufstellung von Speichersystemen geprüftund angepasst?

- Wurden die Überwachungs- und Eskalationsverfahren innerhalbder vorhandenen Betriebsabläufe auf den NAS- oder SAN-Betriebangepasst?



M 2.354 Einsatz einer hochverfügbarenSAN-Lösung

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter

Verantwortlich für Umsetzung: IT-Sicherheitsbeauftragter, Leiter IT

Haben Systeme und Anwendungen, deren Daten im SAN gespeichert werdensollen, einen sehr hohen Schutzbedarf in Bezug auf die Verfügbarkeit aufzu-weisen, so muss der Einsatz einer hochverfügbaren SAN-Lösung in Betrachtgezogen werden.

Der Begriff "hochverfügbar" bezeichnet hier eine hohe Widerstandsfähig-keit gegen Schadensereignisse. Hochverfügbare Lösungen werden allgemeinauch als "Desaster-tolerant" bezeichnet. Bezogen auf die gespeicherten Da-ten einer Institution bedeutet dies, dass mithilfe von SAN-Komponenten einSpeichersystem derart aufgebaut wird, dass

- alle Daten an zwei Standorten vorgehalten werden,- die SAN-Komponenten der Speicherlösung an den beiden Standorten ge-

koppelt, aber nicht abhängig voneinander sind- jede einzelne Komponente redundant konfiguriert ist,- ein Schadensereignis an einem Standort die Funktionalität der Kompo-

nenten am zweiten Standort nicht beeinträchtigt.

Kenngrößen, die anzeigen, ob eine solche Architektur nötig und angemessenist, sind:

- Die maximale Wiederanlaufzeit (engl. RTO: Recovery Time Objective) gibtdie Zeitspanne an, die vergehen darf, bis nach einem SchadensereignisIT-Systeme wieder in hinreichender Funktionalität zur Unterstützung vonGeschäftsprozessen zur Verfügung stehen.

- Der maximal tolerierbare Datenverlust (engl. RPO: Recovery Point Objec-tive): Aus dem Alter des letzten verfügbaren konsistenten Datenbestandeslässt sich die Menge an "verloren gegangener Arbeit" nach dem Eintritt ei-nes Schadensereignisses bemessen. Der maximal tolerierbare Datenver-lust beschreibt im Grunde die Menge oder auch die Komplexität an Arbeit,die mit einem für die Institution tragbaren Aufwand verbunden ist, ohnedass geschäftskritische Verluste zu verzeichnen sind.

- Das betroffene Umfeld umfasst den räumlichen Umfang des Schadenser-eignisses. Nur wenn ein Standort mit seinen Systemen außerhalb der Wir-kung des Ereignisses liegt, bleibt er nützlich.

SAN-Speicherlösungen sind eine Schlüsseltechnik, um sehr hohe Anforde-rungen an die Verfügbarkeit der IT zu erfüllen:

- Sie können bei Erhalt einer leistungsfähigen Kopplung so weit räumlichgetrennt werden, dass auch gegen umfassend wirkende Ereignisse Vor-sorge möglich ist.

- Die mögliche leistungsfähige Kopplung kann genutzt werden, um den ma-ximalen Datenverlust zu minimieren oder gänzlich auszuschließen.

Die maximale Ausfallzeit einer Anwendung kann jedoch nur in Teilen durchdie Konfiguration der Speicherlösung beeinflusst werden. Da die Ausfallzeitausschließlich aus Sicht der Anwender gemessen werden darf, hängt sie nichtnur von der Verfügbarkeit der gespeicherten Daten ab, sondern genauso vonder Verfügbarkeit der übrigen IT-Infrastruktur (Server, Netz, PCs, ...), die vonSAN-Komponenten mit Daten versorgt werden. Des Weiteren sind auch Zeitenbis zur Alarmierung und Rüstzeiten zur Beseitigung der Störung zu betrachten.



Möglichkeit der Konfiguration

Es existieren verschiedene Möglichkeiten, eine Speicherlösung hochverfüg-bar zu konfigurieren.

Spiegelung durch den Server

Die einfachste Möglichkeit des hochverfügbaren SAN-Einsatzes ist dann ge-geben, wenn ein Server, der seine Daten auf einem SAN-Speicher ablegt, anein zweites, räumlich abgesetztes Speichersystem angeschlossen wird.

Jeder Schreibzugriff des Servers wird auf beiden Speichersystemen durchge-führt. Nachteilig an dieser Lösung ist, dass die Konfiguration und Administra-tion der Instanz "Speicher" auf dem Server stattfindet.

Der Vorteil einer zentralen Speicherlösung, an der auch zentral administriertwerden kann, bleibt auf diese Weise ungenutzt. Zudem muss die Verkabelungkomplexer angelegt werden, da jeder Server mit beiden Speichersystemenverbunden wird. Vereinfacht dargestellt muss in Ergänzung der Verbindungzwischen Server und Speichersystem eine zweite Leitung von Server direktzum abgesetzt stationierten zweiten Speichersystem verlegt werden.

Replikation

Replikation kann durch den Server oder durch das Speichersystem erfolgen.Serverbasierte Replikation wird in der Regel über eine eigene Software, dieApplikation oder das Betriebssystem realisiert. Allerdings geht dieser Ansatzmeistens mit einer hohen Belastung von CPU, Hauptspeicher und Bandbreiteeinher.

Bei der Replikation durch das Speichersystem werden die Server mit einemSpeichersystem verbunden, dieses Speichersystem gleicht seinen Datenbe-stand komplett oder entsprechend seiner Konfiguration mit einem weiterenSpeichersystem an einem abgesetzten Standort ab.

Wenn die Standorte nah genug beieinander liegen, ist synchrone Datenrepli-kation möglich. "Synchrone Datenreplikation" bedeutet, dass jeder Schreibzu-griff des Servers von seiner direkt angeschlossenen Speicherplatte erst dannals fertig gemeldet wird, wenn das zweite, abgesetzte Speichersystem demersten Speichersystem das erfolgreiche Schreiben ("Acknowlege") bestätigthat.

Damit werden Festplattenzugriffe aus Sicht der Anwendung langsamer, dazum einen zwei Plattensysteme schreiben und zum anderen die Signallaufzeit(Latenz) zwischen dem Speichersystem an Standort A und dem an StandortB hinzukommt.

Bei der asynchronen Datenreplikation sorgt besondere Replikationssoftwareauf den Speichersystemen dafür, dass das Speichersystem an Standort Aseine veränderten Daten regelmäßig an das Speichersystem an Standort Bübermittelt. Dies geschieht häufig über IP-Verbindungen. Daher ist die Ent-fernung zwischen Hauptstandort und Replikationsstandort nicht begrenzt undkann sich sogar über Kontinente hinweg erstrecken.

Damit hat die Anwendung ein ungebremstes Speichersystem zugeordnet. Einweiterer Vorteil an dieser Stelle ist, dass eine Institution nicht mehr gezwun-gen ist, die exakt identischen Speichersysteme für die Notfallvorsorge an zweiOrten bereitzuhalten. Am Hauptstandort kommt dann ein hochleistungsfähi-ges System zum Einsatz. Am zweiten Standort kann dagegen ein günstigeres



System installiert werden, sodass dennoch die Hauptaufgaben in einem Not-fallszenario gewährleistet werden.

Der Nachteil bei der asynchronen Replikation ist, dass das zweite Speicher-system stets einen älteren, zeitlich versetzten Datenbestand hat. Wie groß derDatenverlust bei Ausfall des primären Systems ist, hängt von der eingesetztenTechnik und der Konfiguration der asynchronen Spiegelung ab.

Synchrone Datenreplikation von Speichersystemen ist meist dann sinnvoll,wenn auch redundante Serversysteme bereitstehen, die den Betrieb direktweiterführen können. Ein Szenario, bei dem an einem Standort das Speicher-system komplett ausfällt, die angeschlossenen Server und Netzkomponentenaber nicht (z. B. die des SANs), ist eher selten.

Weitere Informationen zur Replikation finden sich in M 3.92 GrundlegendeBegriffe beim Einsatz von Speicherlösungen.

Bei der Planung einer hochverfügbaren Speicherlösung muss zunächst dasgesamte Notfallvorsorgekonzept der Institution, zumindest aber der IT-Notfall-vorsorgeteil dieses Konzeptes, geprüft werden. Die Verfügbarkeitsanforderun-gen müssen schriftlich festgelegt werden.

Angepasst an die Anforderungen und die Risikopolitik der Institution ist diePlanung einer hochverfügbaren Speicherlösung nur der erste Schritt in Rich-tung Hochverfügbarkeit. Gleichzeitig muss die Planung der Weiterentwicklungder gesamten IT-Umgebung und der Notfallplanung für die Institution erfolgen.

Eine hochverfügbare Speicherlösung ist nur dann sinnvoll, wenn auch Ser-ver für den Wiederanlauf bereitstehen und wenn die Anwender an intaktenArbeitsplätzen über ein funktionierendes Netz auf Anwendungen und Datenzugreifen können.

Es ist zu beachten, dass ein Test- und Konsolidierungssystem ergänzt wer-den muss. Konfigurationsänderungen und Software-Updates dürfen bei Auf-bau einer hochverfügbaren Konfiguration nie direkt am Produktivsystem vor-genommen werden. Von der Institution sind Systeme vorzuhalten, an denensämtliche Änderungen getestet werden können. Nur so lässt sich sicherstel-len, dass der Betrieb nicht durch fehlerhafte Konfiguration, Software oder ad-ministrative Eingriffe gefährdet wird.

Hochverfügbarkeitsanbindung über den Einsatz von Speicher-Virtualisierung

Eine hochverfügbare Speicher-Virtualisierung ermöglicht durch ihre Funktio-nen den Aufbau einer komplett hochverfügbaren Speicherlösung, die in derLage ist, auf Ausfallszenarien automatisch zu reagieren.

Die Grundlage einer hochverfügbaren Speicher-Virtualisierung stellt die Vir-tualisierungs-Appliance dar. Sie ermöglicht die zentrale Verwaltung allerSpeicherbereiche und wird für eine hochverfügbare Speicherlösung als soge-nannter Cluster ausgeführt. Die Verteilung der Cluster und der Storagesyste-me erfolgt dabei auf zwei unterschiedliche Brandabschnitte.

Die gewählte Architektur sollte in der Lage sein, zu gewährleisten, dass dieDaten immer konsistent auf beiden Storagesystemen vorhanden sind (Spiege-lung). Die Speicher-Virtualisierungslösung ist wiederum in sich redundant auf-gebaut, und bei Ausfall eines Speichersystems arbeiten die Appliances weiter.



Die Funktionalität einer solch hochverfügbaren Speicherlösung mit Spei-cher-Virtualisierung sollte im Rahmen von Tests und Übungen im Rahmen desNotfallmanagements (siehe Baustein B 1.3 Notfallmanagement) getestet undgeübt werden, um sicherzustellen, dass sie auch in Notfällen die geforderteLeistung erbringt. Bei den Tests und Übungen ist das Risiko des Datenver-lusts durch die Tests und Übungen selbst besonders zu beachten. Die Testsund Übungen sind entsprechend auszugestalten, damit es nicht durch sie zueinem Schaden für die Daten der Institution kommt.

Prüffragen:

- Sind die Verfügbarkeitsanforderungen an die Speicherlösung schriftlichfestgehalten?

- Entsprechen die Replikationsmechanismen denVerfügbarkeitsanforderungen?

- Wird die hochverfügbare Konfiguration der Speicherlösung denVerfügbarkeitsanforderungen gerecht?

- Ist ein Test- und Konsolidierungssystem vorhanden?



M 2.355 Auswahl von Lieferanten füreine Speicherlösung

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Nachdem die Anforderungen für eine Speicherlösung spezifiziert wurden, istein geeigneter Lieferant zu identifizieren. Die Auswahl möglicher Lieferantenmuss dabei mehr Kriterien berücksichtigen als die reine Hardwarelösung undderen Preis. Mögliche Auswahlkriterien sind:

- Technische Anforderungen- Kaufmännische Anforderungen (Kauf, Leasing, Storage-on-Demand-

[SoD-] Modelle)- Bestehende Lieferantenbeziehungen- Bestehende Rahmenverträge mit Lieferanten- Flächendeckende Serviceerbringung

Es ist davon auszugehen, dass die Unterstützung des Lieferanten mindestensbei der Lösung von Problemen im Betrieb und erst recht bei Hardwareausfäl-len benötigt wird. Entsprechend sind neben Preisen und Konditionen für dieBeschaffung der Speicherlösung und deren Inbetriebnahme auch die Kondi-tionen und der Leistungsumfang der angebotenen Unterstützung zu bewerten.

Die Aspekte der Wartung und Instandhaltung werden schriftlich im Vertrag imRahmen von sogenannten Service Level Agreements (SLAs) definiert. Ent-sprechend sollte das Angebot eines möglichen Lieferanten neben den Hard-ware- und Softwarepreisen auch die Preise für denkbare SLAs beinhalten,sodass der Kunde die Gesamtpakete vergleichen kann, wenn verschiedeneHersteller oder Lieferanten in Betracht kommen.

Wichtig ist in diesem Zusammenhang auch die Bewertung von zusätzlichenKriterien wie der Servicefähigkeit eines Anbieters, die beispielsweise von derVerteilung einzelner Servicestützpunkte abhängt. Darüber hinaus kann einezentrale Hotline, die durch den Anbieter zur Verfügung gestellt wird, oder derNachweis der Leistungsfähigkeit durch eine signifikante Anzahl entsprechendzertifizierter Mitarbeiter für das gewünschte System ein ausschlaggebenderAspekt sein. Institutionen sollten dazu weiterhin M 2.356 Vertragsgestaltungmit Dienstleistern für Speicherlösungen beachten.

Wenn eine Speicherlösung nicht gekauft, sondern z. B. geleast wird, mussauch vertraglich festgehalten werden, wie bei Vertragsende der Datentransferauf Nachfolgesysteme, die Datenlöschung und andere technische und organi-satorische Fragen gehandhabt werden und welche Kosten hierfür entstehen.

Generell ist festzustellen, dass gerade bei komplexen Systemen eine Lösungaus einer Hand Vorteile haben kann und daher präferiert werden sollte: Inder Regel können Probleme, die beim Aufbau, Test und Betrieb entstehen,schneller und effektiver beseitigt werden, wenn nur ein Anbieter involviert ist.

Bei Lösungen aus Komponenten verschiedener Anbieter können in der An-schaffung preisliche Vorteile erzielt werden. Es ist aber wichtig zu prüfen, obdieser Vorteil auch bestehen bleibt, wenn die Kosten der Umsetzung (Grund-konfiguration, Probebetrieb, Datenmigration) und des Betriebs (Wartung, Un-terstützung bei Problemen) mit betrachtet werden.



Prüffragen:

- Enthält der Vertrag eindeutige und quantifizierbareLeistungsbeschreibungen?

- Sind die Auswahlkriterien und die Auswahl des Lieferantennachvollziehbar dokumentiert?

- Sind genaue Regelungen für das Laufzeitende des Vertrages getroffenworden?



M 2.356 Vertragsgestaltungmit Dienstleistern fürSpeicherlösungen

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Nur wenige Institutionen werden die technische Betreuung der Speicherlösungim Normalbetrieb und in Notfallsituationen selbst vollumfänglich leisten kön-nen und wollen. In diesem Fall müssen sie auf geeignete Hersteller und Lie-feranten zugreifen, im Weiteren kurz als Dienstleister bezeichnet.

Die Aspekte, die im Folgenden beschrieben werden, sind als Hilfsmittel undCheckliste bei der Vertragsgestaltung zu sehen. Art, Umfang und Detaillie-rungsgrad der vertraglichen Regelungen hängen von den Verfügbarkeitsan-forderungen des Auftraggebers und auch von der Komplexität der konkretenSpeicherlösung ab.

Grundsätzlich sollte der Dienstleister auf die Einhaltung aller relevanten Ge-setze und Vorgaben, vor allem aber des Datenschutzes nach dem Bundes-datenschutzgesetz (BDSG) und auf den Einsatz von organisatorischen undtechnischen Maßnahmen zur Informationssicherheit verpflichtet werden. Die-se sollten mindestens dem Niveau des IT-Grundschutzes entsprechen undgegebenenfalls um weitere, vom Auftraggeber vorgegebene, Sicherheitsan-forderungen ergänzt werden.

Neben diesen allgemeinen Verpflichtungen empfiehlt es sich, alle vereinbar-ten Leistungen messbar und prüfbar im Vertrag schriftlich zu fixieren. So kannes z. B. angemessen sein zu vereinbaren, dass ein qualifizierter Mitarbeiterdes Dienstleisters bei bestimmten Problemfällen innerhalb von vier Stundenvor Ort sein muss. Eine solche konkrete, an den Anforderungen der Institutionfestgemachte Aussage kann eventuell sinnvoller sein als ein Pauschalange-bot ("Gold-Support"), das möglicherweise ungünstige Ausnahmen (beispiels-weise "Sonntags nur telefonische Unterstützung") von der geforderten Quali-tät beinhaltet.

Auch die Erstellung des Notfallvorsorgekonzeptes für die Speicherlösung soll-te Vertragsbestandteil sein. Insbesondere ist zu klären, wer für die fachlichenInhalte verantwortlich ist und welche Mitwirkungspflichten dem Auftraggeberobliegen.

Es ist dringend anzuraten, dass der Auftraggeber genügend Vorbereitung indie Zusammenstellung der eigenen Anforderungen investiert. NachträglicheKonkretisierungen und Ergänzungen des Vertrages, die aufgrund unterschied-licher Interpretation von ungenau beschriebenen Leistungen notwendig wer-den, sind oftmals mit deutlichen Kostenerhöhungen für den Auftraggeber ver-bunden.

Insbesondere wenn es sich bei dem Dienstleistungsverhältnis um Outsour-cing handelt, ist der Baustein B 1.11 Outsourcing zusätzlich anzuwenden, beiCloud-Speicherlösungen der Baustein B 1.17 Cloud-Nutzung und insbeson-dere die Maßnahme M 2.541 Vertragsgestaltung mit dem Cloud-Dienstean-bieter. Die folgende Themenliste sollte in diesen Fällen der Konkretisierung



der grundlegenden Anforderungen an die Vertragsgestaltung aus diesen Bau-steinen in Bezug auf Speicherlösungen dienen.

Organisatorische Regelungen und Prozesse- Festlegung von Kommunikationswegen und Ansprechpartnern- Festschreibung von Zeiten (z. B. Tagbetrieb, Nachtbetrieb, was zählt als

Wochenende, Feiertage)- Festlegung von Prozessen, Arbeitsabläufen und Zuständigkeiten- Verfahren bei Störungen, Notfällen, Krisen und sonstigen Sicherheitsvor-

fällen, Benennung von Ansprechpartnern mit den nötigen Befugnissen- Zugriffsmöglichkeiten des Dienstleisters auf IT-Ressourcen des Auftrag-

gebers- Datenübertragung von Wartungs- bzw. Statusinformationen zum Dienst-

leister oder Hersteller- Zutritts- und Zugangsberechtigungen für Mitarbeiter des Dienstleisters zu

den Räumlichkeiten und IT-Systemen des Auftraggebers- Übergabe von Datenbeständen bei Beendigung des Vertragsverhältnis-

ses, Datenlöschung bei Rücknahme von Speichermedien durch den Auf-tragnehmer

Personal- Gegebenenfalls Gestaltung der Arbeitsplätze von externen Mitarbeitern- Festlegung und Abstimmung von Vertretungsregelungen- Planung von Fortbildungsmaßnahmen

Notfallvorsorge- Erforderliche Handlungen beim Eintreten eines Ereignisses mit dem Po-

tenzial zum Sicherheitsvorfall, zum Notfall oder zur Krise- Reaktionszeiten und Eskalationsstufen für solche Ereignisse- Mitwirkungspflicht des Auftraggebers bei der Behebung von Notfällen- Vereinbarung zur Bereitstellung von Ersatz- oder Ausweichsystemen- Von besonderer Bedeutung können Regelungen im Fall höherer Gewalt

sein. Es sollte beispielsweise geklärt sein, wie bei einem Streik des Per-sonals des Dienstleisters die Verfügbarkeit dieses durch z. B. weiteres ex-ternes Personal sichergestellt werden kann.

Haftung, juristische Rahmenbedingungen- Eine Verpflichtung der einzelnen Mitarbeiter des Auftragnehmers auf die

Einhaltung von geltenden Normen und Gesetzen sowie besonderer ver-einbarter Sicherheitsmaßnahmen ist vertraglich zu regeln. Gegebenen-falls sind besondere Geheimhaltungsvereinbarungen vertraglich zu fixie-ren.

- Die Einbindung Dritter, Subunternehmer und Unterauftragnehmer desDienstleisters ist zu regeln. In der Regel empfiehlt es sich nicht, diesegrundsätzlich auszuschließen, sondern sinnvoll zu regeln.

- Die Eigentums- und Urheberrechte an Systemen, Software und Schnitt-stellen sind festzulegen. Es ist zu klären, ob der Dienstleister bereits beste-hende Verträge mit Dritten (Hardwareausstattung, Serviceverträge, Soft-warelizenzen etc.) übernimmt.

- Die Weiterverwendung der vom Dienstleister eingesetzten Tools, Pro-zeduren, Skripte, Batchprogramme ist für den Fall der Beendigung desDienstleistungsvertrags zu regeln.

- Regelungen für das Ende des Vertragsverhältnisses, z. B. für einen Wech-sel oder bei Insolvenz des Dienstleisters, sollten spezifiziert werden.

- Auf ein ausreichend flexibles Kündigungsrecht ist zu achten.- Der Auftragnehmer ist zu verpflichten, nach Beendigung des Auftrags al-

le vom Auftraggeber im Rahmen des Vertragsverhältnisses angeschaffte



Hard- und Software inklusive gespeicherter Daten zurückzugeben sowiealle gespeicherten Informationen sicher zu löschen.

- Haftungsfragen im Schadensfall sind zu klären. Sanktionen oder Schaden-sersatz bei Nichteinhaltung der Dienstleistungsqualität dürfen aus Sichtdes Auftraggebers dabei nicht überschätzt werden.

- Zunächst ist stets zu fragen, wie ein Schaden nachgewiesen bzw. der Ver-ursacher überführt werden kann.

- Wie wird beispielsweise ein Reputationsschaden quantifiziert?- Wie ist es zu bewerten, wenn gravierende Pflichtverletzungen aufgedeckt

werden, die nur zufällig nicht zu einem größeren Schaden geführt haben?- Das Recht auf Schadensersatzzahlungen ist wertlos, wenn diese die Zah-

lungsfähigkeit des Dienstleisters übersteigen und dieser Insolvenz anmel-det.

- Auf der anderen Seite sollten aber "Sanktionen" in Form von kostenloserBereitstellung des Dienstes oder Dienstleistung oder eine kostenlose hö-here Dienstgüte kritisch bewertet werden. Wenn ein Schaden geschäfts-kritisch oder sogar ruinös ist, dann bieten diese kostenlosen Dienste kei-nen Mehrwert.

Änderungsmanagement und Testverfahren- Es müssen Regelungen gefunden werden, die es ermöglichen, dass der

Auftraggeber in der Lage ist, sich neuen Anforderungen anzupassen. Esist festzulegen, wie geänderte Anforderungen des Auftraggebers behan-delt werden.

- Testverfahren für neue Soft- und Hardware sind zu vereinbaren. Dabeisind folgende Punkte einzubeziehen:

- Regelungen für Updates und Systemanpassungen- Zuständigkeiten bei Auftraggeber und Dienstleister bei der Erstel-

lung von Testkonzepten und bei der Durchführung von Tests- Abnahme- und Freigabeprozeduren. Es ist immer wieder zu beob-

achten, dass der Auftragnehmer explizit oder implizit eine Freigabevon Änderungen für den produktiven Betrieb vornimmt, obwohl ge-gebenenfalls beachtliche Risiken und Verantwortung beim Auftrag-geber liegen.

Kontrolle des Auftragnehmers- Die Dienstleistungsqualität muss regelmäßig (z. B. monatlich) kontrolliert

werden. Der Auftraggeber muss die dazu notwendigen Auskunfts-, Ein-sichts- und Zugangsrechte besitzen. Wenn unabhängige Dritte Audits oderBenchmark-Tests durchführen sollen, muss dies bereits im Vertrag gere-gelt sein.

Prüffragen:

- Wurde der Dienstleister auf die Einhaltung aller relevanten Gesetze undVorgaben und auf den Einsatz von organisatorischen und technischenMaßnahmen zur Informationssicherheit verpflichtet?

- Sind alle vereinbarten Leistungen im Vertrag messbar und prüfbarschriftlich fixiert?

- Wird die Dienstleistungsqualität regelmäßig kontrolliert?- Sind die Schnittstellen zwischen Anwender und Dienstleister klar definiert

und deckt dies auch Sonderfälle wie z. B. Sicherheitsvorfälle oder Notfälleab?



M 2.357 Aufbau einesAdministrationsnetzes fürSpeichersysteme

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator

Die Verwaltung und Überwachung von Ressourcen wie SAN- oder NAS-Kom-ponenten, an die hohe Sicherheitsanforderungen gestellt werden, muss ange-messen umgesetzt werden. Der Aufbau eines eigenen LANs, das ausschließ-lich administrativen Aufgaben dient, ist oft der übersichtlichste, effektivste undwirtschaftlichste Weg, um diesen Anforderungen zu genügen. In diesem Ad-ministrationsnetz werden PCs stationiert, die ausschließlich zur Verwaltungkritischer Komponenten dienen.

Grundsätzlich sollen auch innerhalb dieses Netzes nur sichere Protokolle(SSH statt Telnet, HTTPS statt HTTP) zur Administration genutzt werden. Diezumindest logische, wenn nicht gar physische Trennung dieses Administrati-onsnetzes von Produktionsnetz macht jedoch den Einsatz unsicherer Proto-kolle, insbesondere des in vielen Produktionsumgebungen immer noch fastunvermeidlichen SNMP Version 1, tolerierbar.

Konzeption/Planung- Ein sehr einfacher Aufbau eines solchen Netzes kann damit starten, dass

ein separater Switch in Betrieb genommen wird.- Alle Clients der Administratoren werden mit ihrem Netzanschluss an das

Administrationsnetz gebunden.- Alle Server und Systeme mit erhöhtem Sicherheitsbedarf (aktive Netzkom-

ponenten, Speichersysteme) erhalten einen zusätzlichen Netzanschlussund werden damit an das Administrationsnetz gebunden.

- Auf den Servern wird der Administrationszugang der Betriebs- und Anwen-dungssoftware, wo immer das möglich ist, exklusiv an die Netzadresse imAdministrationsnetz gebunden.

Im Administrationsnetz sollten private (wie in RFC-Standard 1918 beschrie-ben) Adressen benutzt werden. Solche Adressen werden in "offiziellen" Net-zen nicht geroutet, so dass ein Anschluss an offizielle Netze, wenn er dennnötig werden sollte, stets NAT (Network Address Translation) und weitereSchutzmaßnahmen, die durch eine Firewall realisiert werden, erfordert.

Im Administrationsnetz sollte auf allen IT-Komponenten durch Nutzung oderEinsatz eines NTP-Servers eine einheitliche Uhrzeit sichergestellt werden. Da-mit wird die Auswertung von Protokollen erleichtert und die Bewertung vonVorfällen, die Wirkung auf mehreren Komponenten zeigen, ermöglicht.

Die verfügbaren Ressourcen für den gesamten Aufbau eines Speichersy-stems sind zu ermitteln. Hierzu gehören sowohl Personalressourcen, die er-forderlich sind, um ein Konzept zu erstellen und umzusetzen bzw. um das Netzzu betreiben, als auch die hierfür notwendigen finanziellen Ressourcen.

Die Ergebnisse sind entsprechend zu dokumentieren.

Es ist zudem zu prüfen, ob im Administrationsnetz zusätzliche Überwachungs-maßnahmen etabliert werden sollten. Zum Beispiel kann durch Einsatz vonnetzbasierten IDS zusätzlich überwacht werden, ob unzulässige Aktivitäten imNetz zu beobachten sind.



Ebenso könnte in einem solchen Netz auch eine zentrale Protokollierung eta-bliert werden, in der eine zentrale Instanz als Protokollserver die Logdatenaller Server und Speichersysteme verwaltet. Es ist zu beachten, dass sol-che besonderen Maßnahmen gegebenenfalls mit der Personalvertretung ab-gestimmt werden müssen.

Falls das Administrationsnetz einen komplexen Aufbau aufweist, sollte derBaustein B 4.1 Heterogene Netze für Aufbau und Prüfung herangezogen wer-den.

Umsetzung

Zunächst ist zu untersuchen, wie ein Produktionsnetz und die darin stationier-ten Server und sonstigen Geräte (aktive Netzkomponenten, Speichersysteme)um ein Administrationsnetz erweitert werden können.

Zunächst sind die Maßnahmen M 2.139 Ist-Aufnahme der aktuellen Netzsi-tuation und M 2.140 Analyse der aktuellen Netzsituation zu bearbeiten. An-schließend sind die Anforderungen an die Netzkommunikation des neu aufzu-bauenden Administrationsnetzes zu ermitteln sowie eine Schutzbedarfsfest-stellung des zukünftigen Netzes durchzuführen.

Die Schutzbedarfsanforderungen des Administrationsnetzes sind aus den be-stehenden IT-Verfahren, die über dieses Netz administriert werden sollen, ab-zuleiten.

Betrieb

Mit Aufnahme des Testbetriebes muss eine Prüfung stattfinden, die die Si-cherheitsvorkehrungen testet und zur Grundlage der Betriebsdokumentationdieses Netzes wird. Typische Prüffragen sind:

- Ist eine durchgängige Trennung des Administrationsnetzes vom Produk-tionsnetz gegeben?

- Werden, wo immer möglich, sichere Dienste (secure shell, https) genutzt?Sind die unsicheren Varianten dieser Dienste (telnet, http) auf den admi-nistrierten Geräten deaktiviert?

- Ist überschaubar und dokumentiert, wo auf den Einsatz unsicherer Dienstenicht verzichtet werden kann?

- Sind alle Default-Kennungen und -Passwörter auf PC, Servern und aktivenNetzkomponenten etc. geändert?

Anschließend kann der produktive Betrieb gestartet werden.

Aussonderung

Wenn PCs oder andere Hardware ausgesondert oder auch nur zur Reparaturzeitweise aus dem Netz genommen werden, ist sicherzustellen, dass keineinternen Informationen (Passwörter, Protokolldateien, Dokumente zu Internaetc.) darauf gespeichert sind.

Notfallvorsorge

Es muss eine Notfallplanung geben, so dass der Betrieb des produktiven Net-zes sichergestellt wird, wenn das Administrationsnetz ausfällt.

Prüffragen:

- Wird die Verwaltung und Überwachung des Speichersystems denSicherheitsanforderungen des Speichersystems gerecht?



- Ist für alle Komponenten des Administrationsnetzes eine einheitlicheUhrzeit sichergestellt?

- Werden während des Testbetriebs des Administrationsnetzes dieSicherheitsvorkehrungen getestet und der Test sowie die Ergebnissedokumentiert?

- Gibt es eine Notfallplanung, so dass bei Ausfall des Administrationsnetzesdas produktive Netz weiterbetrieben werden kann?



M 2.358 Dokumentation derSystemeinstellungen vonSpeichersystemen


Die Dokumentation der Systemeinstellungen zum Speichersystem weist dieUmsetzung von technischen und organisatorischen Vorgaben nach und be-schreibt die individuelle Konfiguration der Institution. Die Dokumentation istGrundlage für die Administration im Normalbetrieb und für die Planung undDurchführung von Änderungen. Zudem ist eine aktuelle und korrekte Doku-mentation Grundlage der Notfallvorsorge.

Daten, die im Notfall relevant sind, müssen in allen Notfallszenarien zugreif-bar sein. Dabei muss jedoch beachtet werden, dass Informationen zu den Sy-stemeinstellungen vertraulich sind und daher ausreichend vor unberechtigtemZugriff geschützt werden müssen.

Dokumentiert werden sollten insbesondere folgende Informationen:

Zur Organisation:

- Eine Beschreibung der definierten Rollen und der zugehörigen Rechtepro-file

- Die administrativen Benutzer des Speichersystems mit zugeteilter Rolle- Der Zeitpunkt der Einrichtung von Benutzerkennungen und -rechten sowie

gegebenenfalls die Befristung und weitere Erläuterungen- Die Kontaktdaten des Benutzers und dessen organisatorische Einbindung- Vorgaben zu Datensicherung und Notfallvorsorge

Zur Technik:

- Die Aufstellung aller Speichergeräte mit Angaben zu Typ, Zweck und An-wenderkreis

- Die logischen und physischen Zuordnungen der Speichergeräte zu denServern

- Sämtliche Anbindungen der Speichergeräte an die Netze (SAN, LAN, ge-gebenenfalls WAN zur Fernüberwachung)

- Eine Aufstellung, welche Geräte über eine NAS-Schnittstelle Daten expor-tieren

- Eine Aufstellung aller Management-Schnittstellen (In-Band und Out-Band). Diese sollte auch eine Übersicht enthalten, welche Schnittstellenaktiv sind und welche Dienste darüber erreichbar sind.

Zur Administration:

- Eine grafische Darstellung der Netze (SAN, LAN, gegebenenfalls WAN)und der konfigurierten Verbindungen zwischen Speichersystemen, Ser-vern und Administrations-PC.

- Alle erforderlichen Angaben zur Aktivierung und Deaktivierung vonSchnittstellen und Diensten.

- Die notwendigen Einstellung für die Datensicherung- Die Einstellungen zur Protokollierung- Empfehlenswert ist eine kurze Darstellung ("Kochbuch") der Handhabung

von wichtigen oder regelmäßig durchzuführenden Administrationstätigkei-ten.



Die Dokumentation zur Organisation sollte regelmäßig (mindestens alle 6 Mo-nate) daraufhin überprüft werden, ob sie den tatsächlichen Stand der Rechte-vergabe widerspiegelt und ob die Rechtevergabe noch den Sicherheitsanfor-derungen und den aktuellen Aufgaben der Benutzer entspricht.

Die technische Dokumentation sollte noch häufiger zumindest stichprobenar-tig überprüft werden, da sie die Grundlage der Notfallvorsorge ist.

Prüffragen:

- Entspricht die Dokumentation der Systemeinstellungen den technischenund organisatorischen Vorgaben und beschreibt sie die spezifischeKonfiguration der Speichersysteme der Organisation?

- Sind die im Notfall relevanten Daten in allen Notfallszenarien verfügbar?- Sind vertrauliche Daten aus der Dokumentation der Systemeinstellungen

vor dem Zugriff Unberechtigter geschützt?- Sind die Vorgaben zu Datensicherung und Notfallvorsorge für

Speichersysteme dokumentiert?- Wurde die Dokumentation zu Speichersystemen (insbesondere der

Rechtevergabe) mindestens alle 6 Monate überprüft?



M 2.359 Überwachung und Verwaltungvon Speicherlösungen


Um Fehlersituationen und Sicherheitsprobleme zeitnah erkennen und behe-ben zu können, ist es notwendig, den laufenden Betrieb von Speicherlösungenzu überwachen. Voraussetzung für eine solche Überwachung ist die Möglich-keit, Daten von verschiedenen Quellen (Server, Switches, Speichersystemeusw.) auszuwerten.

Eine Speicherlösung besteht aus einer Vielzahl von Komponenten, die zuüberwachen sind:

- Daten über den Zustand der Hardware der Speicherlösung,- Daten zur Auslastung der Speicherlösung und- Daten über die Netzinfrastruktur (IP und FC)

Alle Daten sollten dabei vorrangig daraufhin geprüft werden, ob die Vorgabendes Betriebshandbuchs umgesetzt bzw. eingehalten werden.

Eine effiziente Analyse der Daten ist in der Regel nur realisierbar, indemspezielle Anwendungen zum automatisierten Monitoring und Reporting ein-gesetzt werden. Dabei muss eine Vielzahl von Daten gesammelt und ausge-wertet werden. Daher sollte unter anderem durch Einsatz oder Nutzung einesNTP-Servers eine einheitliche Datums-/Uhrzeiteinstellung auf allen Gerätenerzwungen werden. Wichtige Nachrichten, die auf Basis von SNMP gesendetwerden, können durch den Einsatz von Nachrichtenfiltern herausgefiltert undsomit schneller erkannt werden.

Spezielle Produkte zur Überwachung ermöglichen je nach Ausprägung sowohleine Statusüberwachung als auch die Anpassung von Einstellungen in Echt-zeit. Der Netzadministrator kann bei auftretenden Problemen automatisch ge-warnt werden, bevor diese zu Ausfällen führen.

Die Überwachung von Ereignissen der gesamten Speicherlösung (FC/IP-Ports, Netz- und Speichersysteme) und Umgebungsparameter gestattet einefrühzeitige Fehlererkennung und -isolierung sowie eine Indikation der Verfüg-barkeit und Leistungsfähigkeit der gesamten Umgebung.

In diesem Zusammenhang müssen folgende Komponenten überwacht wer-den:

- Die Anwendungen, die in einer Speicherlösung Daten verarbeiten odereine Hilfsfunktion haben. Dazu gehören die Sicherungssoftware und auchAntiviren-Software

- Die Menge der Nutzdaten, die von Anwendungen verarbeitet und dannüber das Speichernetz vom Server auf Speichersysteme transportiert wer-den (Kapazitätsmanagement)

- Die Netzhardware, die für den Transport der Daten benötigt wird- Die Speicherhardware (Plattensysteme, Bandlaufwerke), die zur Speiche-

rung der Daten benötigt wird- Das Netz - Bei einem NAS-System ist das TCP/IP-Netz zu überwachen,

bei einem SAN das speicherinterne Netz und zudem das zusätzlich zurSteuerung und Verwaltung genutzte lokale Netz.

Eine erweiterte Möglichkeit der Überwachung von Speicherlösungen bietet derEinsatz sogenannter Security Information and Event Management-Lösungen



(SIEM). Diese sind in der Lage, Ereignis-, Bedrohungs- und Risikodaten zu-sammenzufassen. Auf dieser Basis können sie Sicherheitsinformationen lie-fern und schnelle Reaktionen auf Sicherheitsvorfälle sowie die Protokollver-waltung und Erzeugung von Compliance-Berichten sicherstellen.

Neben der Überwachung der Ressourcen sollte auch die Verwaltung einzelnerKomponenten und des Gesamtsystems von zentraler Stelle aus möglich sein.Systeme, die eingesetzt werden, um die Speicherlösungen zu steuern oder zukontrollieren, werden oft als Speichermanagementsysteme bezeichnet. Idea-lerweise verfügen Managementsysteme über die Möglichkeit, auf eine Repor-ting-Historie zuzugreifen. Auf diesem Weg können Ereignisse und Störungen,die in der Vergangenheit liegen, nachträglich untersucht werden und entspre-chende Erkenntnisse der Stabilisierung des Gesamtsystems dienen.

NAS-Management

Die Überwachung von reinen NAS-Lösungen ist häufig besonders einfach ge-staltet. Auch wenn das System scheinbar "wartungsfrei" erscheint, ist es nö-tig, technische und/oder organisatorische Überwachungsmaßnahmen zu eta-blieren. Nach Möglichkeit sollte die NAS-Lösung in ein einfaches Netzmana-gementsystem eingebunden werden, um mindestens zu kontrollieren, ob dieNAS-Lösung verfügbar ist und hinreichend Speicherkapazität aufweist.

SAN-Management

Bei der Überwachung von SAN-Lösungen stehen die Mechanismen des "In-Band-Managements" und des "Out-of-Band-Managements" zur Verfügung.

In-Band-Management findet auf den Schnittstellen und Netzen statt, die demDatentransport zwischen den SAN-Geräten dienen. Die Möglichkeiten derKonfiguration und der Überwachung sind beim In-Band-Management häufigweitreichender und komfortabler, da die zugrunde liegende Software produkt-nah ist und Hersteller hier Alleinstellungsmerkmale suchen.

Das Out-of-Band-Management benutzt dagegen zusätzliche Schnittstellen,üblicherweise TCP/IP-Netzanschlüsse. Als Protokoll zur Informationsgewin-nung ist SNMP weit verbreitet. Out-of-Band-Management bietet die üblichenStandards und erleichtert die Kombination von Produkten unterschiedlicherHersteller.

Da als Protokoll beim Out-of-Band-Management oft noch die wenig siche-re SNMP Version 1 genutzt wird, ist ein separates abgeschottetes Manage-ment-LAN zu betreiben (siehe M 2.357 Aufbau eines Administrationsnetzesfür Speichersysteme). Grundsätzlich sollen auch innerhalb dieses Netzes nursichere Protokolle (SSH statt telnet, HTTPS statt HTTP) zur Administrationgenutzt werden. Die zumindest logische, wenn nicht gar physische Trennungdieses Administrationsnetzes vom Produktionsnetz macht jedoch den Einsatzunsicherer Protokolle tolerierbar.

Bei höheren Anforderungen an die Verfügbarkeit der Managementlösungsollte eine Kombination der beiden dargestellten Varianten gewählt werden.Wenn sowohl In-Band- als auch Out-of-Band-Management und Überwachungim Einsatz sind, erleichtert und beschleunigt die zusätzliche Netzanbindungdie Überwachung und Diagnose von Problemen, erhöht jedoch auch den Be-triebsaufwand.



Zentrale Kontrolle

In größeren Installationen, vor allem bei Speicherlösungen mit verschiedenenStandorten der Komponenten, sollte eine zentrale Stelle existieren, an die allefür den Betrieb wichtigen Informationen gemeldet werden. Der Einsatz vonProgrammen, die das Geschehen übersichtlich grafisch darstellen können, istratsam.

Ein solches Managementsystem stellt die Schnittstelle zu einem komplexenSystem dar. Es kann nur von hinreichend geschultem Personal effizient ge-nutzt werden.

Sofern eine Speicherlösung durch einen externen Dienstleister betrieben wird,sind in Abhängigkeit der Vertragsgestaltung Service Level Agreements (SLAs)geschlossen worden. In diesem Fall sollte eine Institution Festlegungen tref-fen, wie die Einhaltung dieser vertraglichen Regelungen überwacht werdenkann (z. B. durch regelmäßiges Reporting und Kontrolle) bzw. welche Infor-mationspflichten für den Dienstleister mit diesen einhergehen.

Prüffragen:

- Gibt es dokumentierte Festlegungen und Prozesse zur Überwachung undVerwaltung der Speicherlösung?

- Gibt es eine zentrale Stelle, an die Informationen unterschiedlicherSpeicherlösungen gemeldet werden?

- Sind Nachrichtenfilter im Einsatz, um die wesentlichen Nachrichtenherauszufiltern und besser darzustellen?

- Sind Festlegungen getroffen und dokumentiert wurden, die dieÜberwachung vertraglich vereinbarter SLAs mit dem Dienstleister regeln?



M 2.360 Sicherheits-Auditsund Berichtswesen beiSpeichersystemen


Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter,Revisor

Umfang und Häufigkeit von Sicherheitsüberprüfungen auf Speichersystemenwerden durch die Daten, die auf dem jeweiligen Speichersystem verarbeitetwerden, bestimmt. Bei komplexen Systemen, in denen eine Vielzahl von An-wendungen ihre Daten auf dem Speichersystem ablegen, muss eine Analyseder Geschäftsprozesse und eine darauf abgestimmte Feststellung des Schutz-bedarfs vorgenommen werden. Dabei ist für Anwendungen und Daten, diedie wesentlichen Geschäftsprozesse unterstützen, der Schutzbedarf festzu-stellen, um Anforderungen an die Häufigkeit und Tiefe von Sicherheits-Auditszu erhalten. Wie üblich geben die strengsten Anforderungen einer einzelnenAnwendung die Vorgabe für das Gesamtsystem.

Zur Überwachung aller sicherheitsrelevanten Tätigkeiten muss ein Prozesseingerichtet werden. In diesem muss festgelegt sein, welche Sicherheitsre-ports regelmäßig erstellt werden. Da Speichersysteme komplex zusammen-gesetzt sein können, müssen Sicherheitsreports relevante Beobachtungenaus verschiedenen Quellen zusammenstellen und bewerten. Zudem mussfestgelegt werden, wie mit Abweichungen von den Vorgaben umgegangenwird. Die Sicherheitsreports sollten als Information für den Auditor verwendetwerden.

Inhalt eines Audits

Ein Audit gleicht die Sicherheitsvorgaben mit den aktuellen Einstellungen undDaten ab. Durch ein solches Audit wird überprüft, ob die geforderten Sicher-heitseinstellungen und Abläufe eingehalten werden.

Ziel des Sicherheitsaudits

Wichtig ist, dass ein Audit nur zur Feststellung von Tatsachen und nicht zurErmittlung von Schuldigen dient, siehe auch M 2.199 Aufrechterhaltung derInformationssicherheit.

Sicherheits-Berichtswesen

Das Resultat eines Audits kann als eine einfache Soll-Ist-Gegenüberstellunggehalten werden. Der Bericht soll in gebotener Kürze die Vorgaben z. B. ausder Sicherheitsrichtlinie darstellen und die Feststellungen des Audits zu deneinzelnen Vorgaben darstellen. Wenn Abweichungen vom Soll gefunden wer-den und Maßnahmen zur Besserung bekannt sind, so sollten diese direkt inden Report geschrieben werden.

Unabhängigkeit der Auditoren

Die Durchführung der Audits muss durch unabhängige Auditoren erfolgen,d. h. das durchführende Personal darf sich und seine Arbeit nicht selbst au-ditieren.



Auch wenn die Tätigkeit der Auditoren durch die Administratoren des Spei-chersystems unterstützt wird, benötigen sie tiefere Kenntnisse über das Spei-chersystem zur Durchführung ihrer Tätigkeit. Diese Kenntnisse sind durch re-gelmäßige Schulungen zu erwerben bzw. zu aktualisieren.

Autorisierung der Auditoren

Wenn die Auditoren selbstständig und ohne Unterstützung durch die Admini-stratoren tätig werden sollen, so ist eine Rolle "Auditor" für alle Komponen-ten des Speichersystems zu definieren. Die Rechte zu dieser Rolle sollten als"Nur Lesen" aller Einstellungen und Logdateien des Speichersystems definiertwerden.

Wenn keine konkreten Vorgaben der Institution vorliegen, so sollte der Auditormindestens die folgenden Bereiche prüfen:

- Es gibt ein Sicherheitskonzept für die technische Ausgestaltung und orga-nisatorische Regelungen des Speichersystems.

- Der Schutzbedarf der gespeicherten Daten in Bezug auf Verfügbarkeit undVertraulichkeit wurde nach Vorgaben der Anwender festgelegt und doku-mentiert.

- Bei Inbetriebnahme wurden in allen Komponenten (Speicher, Sicherungs-geräte, gegebenenfalls SAN-Switche), Administrations-PC und zusätzli-cher Software die Standardpasswörter ersetzt.

- Alle Komponenten (Speicher, Sicherungsgeräte, gegebenenfalls SAN-Switche) sind in zutrittsgeschützten Räumen mit angemessener Infrastruk-tur (Stromversorgung, Klimatisierung) stationiert.

- Administrative Zugriffe auf Speichersysteme erfolgen ausschließlich überein separates Administrationsnetz.

- Das Administrationsnetz ist durch Firewall, Anti-Viren-Software und gege-benenfalls ein IDS abgesichert.

- Zur Administration werden nur gesicherte Verbindungen (z. B. über https,ssh) genutzt.

- Der Zugriff auf die Speichersysteme und ihre Daten ist ausreichend ge-schützt und vom restlichen Institutionsnetz geeignet abgetrennt.

- Die Daten werden verschlüsselt transportiert bzw. gespeichert, wenn diesaufgrund ihres Schutzbedarfs erforderlich ist.

- Das Logging ist so eingestellt, dass Fehlersituationen und Missbrauchs-versuche protokolliert werden. Die Protokolldateien werden regelmäßigkontrolliert.

- Grundkonfiguration und folgende relevante Änderungen der Konfigurationsind schriftlich dokumentiert. Ein Netzplan der Topologie der Speichersy-steme und ihrer Verbindungen zum LAN ist vorhanden und aktuell. DieseDokumentation ist auch im Notfall verfügbar.

- Nach Änderungen werden sicherheitsrelevante Einstellungen des Spei-chersystems erneut überprüft.

- Der störungsfreie Ablauf von Datensicherungen und die Brauchbarkeit vonSicherungsmedien werden regelmäßig kontrolliert.

Prüffragen:

- Gibt es einen Überwachungsprozess für alle sicherheitsrelevantenTätigkeiten und Quellen eines Speichersystems, in dem festgelegt ist,welche Sicherheitsreports regelmäßig erstellt werden?

- Ist geregelt, wie mit Abweichungen von Vorgaben umgegangen wird?- Werden Umfang, Tiefe und Häufigkeit der Sicherheits-Audits auf

Speichersystemen von den darauf verarbeiteten Daten und demSchutzbedarf ihrer Anwendungen bestimmt?



M 2.361 Außerbetriebnahme vonSpeicherlösungen

Verantwortlich für Initiierung: Informationssicherheitsmanagement,Leiter IT

Verantwortlich für Umsetzung: Administrator

Werden Speicherlösungen, einzelne Komponenten oder einzelne Datenträgeraus einer Speicherlösung nicht mehr benötigt, so ist zunächst sicherzustellen,dass alle Daten, die auf dieser Speicherlösung gespeichert sind, in geeigneterWeise auf andere Speicherlösungen übertragen werden.

Anschließend ist sicherzustellen, dass alle Nutzdaten und Konfigurationsda-ten sicher gelöscht werden.

Austausch von Systemkomponenten und Speichermedien

Sind einzelne Speichermedien oder Systemkomponenten defekt und müssendeshalb ausgetauscht werden, ist sicherzustellen, dass die ausgetauschtenSpeichermedien und Komponenten durch Externe, wie z. B. durch den Her-steller, so behandelt werden, dass die Daten nicht reproduziert werden kön-nen.

Wenn hoher oder sehr hoher Schutzbedarf der Daten festgestellt wurde, soll-te mit dem Hersteller oder Händler vereinbart werden, dass die betreffendenPlatten physisch vernichtet werden. Ein Nachweis des Herstellers oder desLieferanten ist gegenüber der Institution zu führen.

Festplatten löschen

Wenn intakte Festplatten ausgetauscht werden, die gegebenenfalls weiterver-wendet werden können oder sollen, müssen die darauf gespeicherten Datenso gelöscht werden, dass ihr Inhalt nicht mehr reproduziert werden kann (sie-he auch M 2.167 Auswahl geeigneter Verfahren zur Löschung oder Vernich-tung von Daten).

Für SAN- und NAS-Festplatten in komplexen Speicherlösungen sind spezielleLöschprogramme des Herstellers erforderlich. Das Löschen kann dann durchdas mit der Wartung beauftragte Unternehmen durchgeführt werden. Dazumuss eine vertragliche Vereinbarung mit einer entsprechenden Verpflichtungdes Dienstleisters vorgenommen werden. Auch hierzu ist gegenüber der In-stitution ein Nachweis zu führen.

Das nachweisliche sichere Löschen einzelner Speichermedien (z. B. Festplat-ten) innerhalb einer Speicherlösung kann in der Regel problemlos umgesetztwerden. Weitere Informationen zur Frage, wie nicht nur bestimmte Speicher-medien, sondern bestimmte Daten in Speicherlösungen gelöscht werden, sindnicht in dieser Maßnahme enthalten. Siehe dazu die Maßnahme M 2.527 Si-cheres Löschen in SAN-Umgebungen.

Abbau einer Speicherlösung

Wenn eine Speicherlösung außer Betrieb genommen werden soll, ist zunächstein Vorgehen zur Migration der Daten zu entwerfen. Es muss sichergestelltsein, dass alle Daten der Speicherlösung in geeigneter Form in andere Spei-cherlösungen überführt werden. In geeigneter Form heißt, dass alle Anforde-



rungen, die sich aus der Tätigkeit der Institution ergeben, aber auch gesetzli-che Anforderungen zu Aufbewahrungsfristen und dergleichen erfüllt werden.

Es empfiehlt sich, eine Übergangsphase einzuplanen. In dieser Zeit werdenbereits die Daten aus der neuen Speicherlösung im aktiven Betrieb genutzt,jedoch ist es noch möglich, auf die Daten der alten Speicherlösung zuzugrei-fen. So wird erreicht, dass auch spät erkannte Probleme noch behoben wer-den können.

Erst wenn die Transitionsphase als abgeschlossen erklärt wird, können dieNutzdaten gelöscht werden. Dazu sollte mit dem Hersteller bzw. Lieferantenein effizientes, an den Schutzbedarf der Daten angepasstes Verfahren ausge-wählt werden. Im Zweifel ist für alle Platten der Speicherlösung das Verfahrenwie bei Austausch einzelner Platten zu wählen. Gerade ab höherem Schutz-bedarf bezüglich Vertraulichkeit kann es sinnvoller sein, alle Platten physischzu zerstören, da der Wiederverkaufswert in keinem Verhältnis zum Schadendurch möglichen Vertraulichkeitsverlust steht.

Verwaltungsinformationen entfernen

Die IP-Adressen bei NAS-Systemen bzw. LUNs und ähnliche Angaben beiSAN-Komponenten müssen aus der Konfiguration entfernt werden. Ebenso istsicherzustellen, dass sonstige Verwaltungsinformationen zuverlässig entferntwerden. Dazu gehören beispielsweise Informationen, die z. B. von einem We-bserver, der als Administrationswerkzeug auf dem System läuft, gespeichertwerden.

Wegen der Sensibilität dieser Informationen ist darauf zu achten, dass die Da-teien vor der Außerbetriebnahme oder dem Austausch defekter oder veralte-ter Komponenten gelöscht beziehungsweise unlesbar gemacht werden. DieVorgehensweise hängt dabei stark vom Hersteller der Komponenten ab. In derSicherheitsrichtlinie für Speicherlösungen sollten hierfür entsprechende Ver-antwortlichkeiten definiert werden.

Viele Komponenten unterstützen einen sogenannten Factory Reset. Dieserführt häufig jedoch nicht zur Löschung aller sicherheitsrelevanten Informatio-nen, sodass weiterhin Restinformationen vorhanden sein können. Eine an-schließende Kontrolle ist daher zwingend erforderlich. Auf anderen Kompo-nenten können Konfigurationsdateien durch entsprechende Befehle komplettgelöscht oder durch andere Dateien ersetzt werden. Sollten die eingesetztenKomponenten über keine der erwähnten Funktionen verfügen, ist eine indivi-duelle Umkonfiguration oder die physische Zerstörung des Speichers erfor-derlich.

Lizenzschlüsselverwaltung

Es muss geprüft werden, ob Softwarelizenzen (z. B. für Antiviren-Software)nicht mehr benötigt und daher abbestellt werden können.

Dokumentation

Eine Abschlussdokumentation über die Datenmigration und die Datenlö-schung ist anzulegen.

Die Dokumentation zur Notfallplanung ist zu kontrollieren und zu aktualisieren.Auch funktionale Abhängigkeiten in Planungen zum Wiederanlauf nach Stö-rungen müssen an die neue Konfiguration angepasst werden. In der Notfall-



dokumentation und der Betriebsdokumentation dürfen keine Verweise mehrauf die außer Betrieb genommene Speicherlösung existieren.

Prüffragen:

- Wird sichergestellt, dass alle Nutzdaten und Konfigurationsdaten sichergelöscht werden, wenn diese nicht mehr benötigt werden?

- Wurde eine Übergangsphase für die Einführung einer neuenSpeicherlösung eingeplant?

- Werden Verweise auf die außer Betrieb genommene Speicherlösung ausallen relevanten Dokumenten entfernt?



M 2.362 Auswahl einer geeignetenSpeicherlösung



Um fundiert zu entscheiden, welche Speicherlösung im jeweiligen Anwen-dungsfall angemessen ist, sind die technischen Grundlagen unterschiedlicherTechniken detailliert zu beleuchten und deren Auswirkungen auf den mögli-chen Einsatz in der Institution zu prüfen. Die Entscheidungsgrundlagen müs-sen dabei nachvollziehbar dokumentiert werden.

Network Attached Storage

NAS-Systeme sind spezielle Speichersysteme, die dem Client Speicherplatzals nutzbares Dateisystem zur Verfügung stellen. Als Dateisystem werdenhierfür meistens Windows (SMB/CIFS) oder Unix (NFS) zur Auswahl gestellt.NAS-Systeme sind sehr einfach in eine bestehende Netzinfrastruktur zu inte-grieren. Sie können wie Server an das Netz der Institution angeschlossen wer-den. Entsprechend sind NAS-Systeme oft als "Appliance" ausgeführt. Sie wer-den betriebsfertig ausgeliefert und können nach einigen elementaren Konfi-gurationen (z. B. der Netzeinstellungen) in Betrieb genommen werden. Basis-software eines NAS-Systems ist üblicherweise eine für diesen Einsatzfall mi-nimierte und optimierte Version eines Standard-Betriebssystems (häufig Unixoder Linux, gegebenenfalls auch Windows).

Abbildung: Schematische Darstel-lung eines Network Attached Storage

Die einfache Anbindung erweist sich gleichzeitig als ein Nachteil von NAS,da die NAS-Systeme über Ethernet-Technik mit den Servern beziehungswei-se Clients verbunden sind. Die darunter liegenden TCP/IP-Protokolle habeneinen relativ geringen Durchsatz und verwenden dabei einen relativ großenProtokoll-Overhead. So sind sie im Grunde nicht für den schnellen Zugriffauf Massenspeicher ausgelegt. Werden NAS-Systeme eingesetzt, kann dar-aus eine hohe Belastung des LANs folgen. In vielen Anwendungsfällen ist je-doch festzustellen, dass eine Gigabit-Ethernet-Anbindung im Realbetrieb hin-reichend schnell ist und durch eine geeignete Architektur des LANs Engpässede facto nicht zu beobachten sind.



Durch die Verwendung von Standardnetzen und Standardprotokollen besit-zen NAS-Systeme die gleichen Schwachstellen, die auch Unix- oder Win-dows-Server betreffen.

Weniger geeignet sind Standard-NAS-Systeme als Speicherlösung für An-wendungen, die nicht dateiorientiert arbeiten. Darunter fallen alle größerenDatenbanken und zum Beispiel auch Microsoft Exchange-Server. Wenn einesolche Anwendung auf einem NAS-System betrieben werden soll, ist zu über-prüfen, ob Produkte am Markt verfügbar sind, die spezifisch für den Betriebdes Produktes und das Einsatzszenario optimiert sind.

Ein NAS-System kann oft für eine Reihe von Servern zum Einsatz kommen.Obwohl die reinen Hardwarekosten meistens deutlich höher sind als der Aus-bau der einzelnen Server mit mehr und/oder größeren Festplatten, kann da-durch die Verfügbarkeit erheblich verbessert werden. Deutliche Vorteile lie-gen in der oft vorhandenen Möglichkeit, durch Konfiguration des Geräts oderHardwareerweiterungen im laufenden Betrieb Kapazitätsanforderungen ohneStillstand zu erfüllen. Verbesserungen sind auch bei der Datensicherung zuerzielen. Mit direkt angeschlossenen Datensicherungsgeräten (Bandlaufwer-ken, Optical Discs, Jukeboxen zur Archivierung) ausgestattet, kann eine Ver-einfachung, Beschleunigung und Stabilisierung bei der Sicherung von Daten-beständen, die über gewachsene Serverlandschaften verteilt sind, erzielt wer-den.

Ein Nachteil von einfachen NAS-Systemen ist, dass ein Ausfall oft weiter rei-chende Folgen hat als der Ausfall eines einzelnen Servers und dass ein Ausfallnicht einfach durch ein in der Institution kurzfristig verfügbares Ersatzsystemkompensiert werden kann.

Storage Area Networks

SANs bestehen aus Plattensubsystemen, Datensicherungssystemen und ei-ner eigenen Netzinfrastruktur. Plattensubsysteme fassen intern eine Mengevon Festplatten zusammen. Hier wird unterschieden, ob diese Zusammenfas-sung lediglich durch ein gemeinsames Gehäuse und eine gemeinsame Strom-versorgung geschieht (JBOD = Just a Bunch of Disks) oder ob ein speziellesSchaltgerät, der sogenannte RAID-Controller mithilfe der RAID-Technik (RAID= Redundant Array of Independent Discs) die physischen Festplatten zu vir-tuellen Festplatten zusammenfasst. Darüber hinaus gibt es intelligente RAID-Controller, die weitere Dienste zur Verfügung stellen können.

Abbildung 2: Schematische Darstel-lung eines Storage Areas Networks

Durch die Zusammenfassung mehrerer physischer Festplatten zu virtuellenEinheiten (Pools), auch "Speichervirtualisierung durch Pooling" genannt, kann



durch geschicktes Kombinieren von physischen Festplatten die Ausfallsicher-heit oder die Performance des Gesamtsystems oder beides erhöht werden.Der Speicher-Controller zeigt nach außen nur die zusammengefassten Fest-platten (virtuelle Festplatte oder logisches "Volume") und verteilt die Daten, dieer auf einer solchen Festplatte schreiben soll, auf die einzelnen physischenFestplatten.

Diese Funktionalität kann auch im Server mithilfe einer speziellen Applikation,dem "Volume Manager", umgesetzt werden, wobei dann der Server stärkerbelastet wird.

Es existieren verschiedene Algorithmen, nach denen die Datenverteilung ge-regelt wird, die sogenannten RAID-Level. Wenn das RAID-Level die Speiche-rung von redundanten Informationen unterstützt, bleiben die gespeichertenInformationen selbst nach dem Ausfall einer Festplatte intakt und können re-konstruiert werden. Oft können einzelne Festplatten des Plattensubsystemsim laufenden Betrieb ausgetauscht werden ("hot swap").

Plattensubsysteme bieten die Möglichkeit, alle Teilkomponenten redundantauszulegen und können somit zur Erhöhung der Verfügbarkeit eingesetzt wer-den. Ein weiterer Vorteil ist, dass durch passende Konfigurationsmechanis-men der einer Anwendung zugeordnete Speicherplatz an ihren Platzbedarfangepasst werden kann.

Ein Plattensubsystem stellt lediglich Speicher für die Anwendungen zur Verfü-gung. Selbst bei redundanter Speicherung der Daten ist eine zusätzliche Da-tensicherung notwendig, da z. B. logische Fehler beim Datenbestand durchHardwareredundanz im Speichersystem nicht korrigiert werden können. AlsSysteme zur Datensicherung sind Bandlaufwerke, optische Medien, aber auchwiederum spezielle Festplattensysteme nutzbar. Auch diese Geräte werdendirekt in das Speichernetz integriert.

SANs verwenden eine eigene Netzhardware und eigene, für den Anwen-dungsfall geeignete schnelle Netzprotokolle. Meistens sind Glasfaserkabel imEinsatz (Systembezeichnung: Fibre Channel, kurz FC). Ein einfaches StorageArea Network besteht aus einem Fibre-Channel-Switch oder -Director (größe-re Switches, die mit mehr Funktionalität ausgestattet sind, werden oft als Di-rector bezeichnet), einem oder mehreren Plattensubsystemen und den Ser-vern, die über sogenannte Host Bus Adapter, kurz HBA, mit dem Fibre-Chan-nel-Switch verbunden werden.

Fibre-Channel-Netze verwenden ein spezielles, an die Anforderung von Mas-senspeichernutzung angepasstes Protokoll, das hohe Übertragungsraten er-möglicht und deshalb für Speichersysteme sehr geeignet ist. Ebenfalls möglichist der Einsatz von iSCSI-Geräten. iSCSI nutzt hierbei das IP-Netz und "ver-packt" Speicherprotokolle, also Steuerbefehle für Massenspeicher und zuge-hörige Daten, in IP-Pakete. iSCSI wird eingesetzt, um über eine virtuelle En-de-zu-Ende-Verbindung den Zugriff von Servern mittels iSCSI Host Bus Ad-apter auf das Speichernetz zu ermöglichen, ohne dass eigene Speichernet-ze betrieben werden müssen. Vorhandene Netzkomponenten (LAN-Switches)können genutzt werden, es muss keine neue oder von der vorhandenen Netz-technik verschiedene Hardware für die Verbindungen zwischen Servern undSpeichergeräten eingesetzt werden. Der Begriff SAN wird im Folgenden fürbeide Techniken verwendet. Wenn eine Unterscheidung notwendig sein sollte,wird "Fibre Channel SAN" oder FC-SAN und entsprechend iSCSI-SAN oderIP-SAN verwendet.



Ein großer Vorteil von SANs ist ihre Desaster-Toleranz. Das Konzept des Mul-ti-Pathings, das im SAN konsequent verfolgt wird, spielt dabei eine wesentli-che Rolle: Falls es einem Server möglich ist, ein Plattensubsystem über meh-rere Host Bus Adapter und über unterschiedliche Netzverbindungen zu er-reichen, so kann der Datentransfer zwischen beiden Systemen auf mehrereDatenwege verteilt werden. Durch den Einsatz mehrerer Host Bus Adapterin den Servern und die Präsentation der virtuellen Festplatten auf mehrerenSchnittstellen eines Plattensubsystems lassen sich somit die mögliche Über-tragungsgeschwindigkeit und Verfügbarkeit des Speichersystems effektiv stei-gern. Wenn zwei oder mehr Host Bus Adapter in einem Server genutzt wer-den, so wird bei Ausfall eines Adapters die Last auf den oder die verbleiben-den HBAs verlagert. Dieses für Betriebssystem und Anwendungen transpa-rente "Failover" verbessert somit die Verfügbarkeit des Servers. Entsprechendkann durch eine redundante Auslegung aller Teilkomponenten eines SANs ei-ne sehr hohe Ausfallsicherheit erreicht werden. Die Maßnahme M 2.354 Ein-satz einer hochverfügbaren SAN-Lösung beschreibt dieses Thema ausführli-cher.

So wäre es in einem kleinen Storage Area Network denkbar, dass sich an zweimöglichst weit auseinander liegenden Orten auf dem Betriebsgelände jeweilsein baugleiches Speichersystem befindet. Jedes dieser Speichersysteme istmit einem von zwei wiederum getrennt installierten Switchen verbunden. Umeine redundante Verbindung zum SAN zu gewährleisten, verfügen die Serverzumindest über zwei Host Bus Adapter, sodass jeder Host Bus Adapter miteinem der beiden SAN-Switches verbunden ist. Somit wäre ein Ausfall einzel-ner Leitungen, eines HBAs, eines Switches oder sogar eines Speichersystemsohne Beeinträchtigung der Gesamtsystemleistung denkbar.

Beim Design eines SANs ist es leicht möglich, Redundanzen zu schaffen, so-dass ein Ausfall einzelner Komponenten wie Kommunikationsleitungen, Swit-chen oder sogar eines Plattensubsystems, keine Beeinträchtigung der Ge-samtsystemleistung bewirkt.

Bei höchsten Anforderungen an die Verfügbarkeit kann dieser Ausbau so er-weitert werden, dass in zwei oder mehr räumlich weit auseinander liegenden(bis zu 100 km) und technisch autarken Rechenzentren jeweils in allen Kompo-nenten redundante SANs aufgebaut werden. So kann im Extremfall der Aus-fall eines kompletten Rechenzentrums ohne Betriebsunterbrechung oder Ka-pazitätsverlust für die Anwender kompensiert werden.

Weitere Redundanz lässt sich durch "Cluster"-Server erreichen, die eine lo-gische Maschine auf zwei oder mehr physische Server verteilen. Dabei wirdeine Anwendung auf zwei oder mehr Servern installiert. Diese Server arbeitenmit denselben Anwendungsdaten. Falls ein Server eine Störung erleidet, über-nimmt der zweite Server automatisch die Arbeit der ausgefallenen Hardware.

Erkauft werden die positiven Eigenschaften einer SAN-Lösung durch Preisund Komplexität. Die selbe Menge Speicher ist in der Realisierung durch einSAN um ein Vielfaches teurer als in der Ausführung als Direct Attached Sto-rage oder NAS.

Zudem ist auch die Planung und der Aufbau eines SANs sehr komplex, so-dass die Institution speziell geschultes Personal einstellen muss oder externeUnterstützung benötigt.



Zusammenfassung

Kurz dargestellt ist NAS eine Speicherlösung mit dateibasiertem Zugriff, SANeine Speicherlösung mit blockbasiertem Zugriff. SAN setzt also "tiefer" an undbietet alle technischen Möglichkeiten, die für die Datenspeicherung angebo-ten werden. NAS ist als Erweiterung der Serverlandschaft einer Institution an-zusehen.

Hybrid-Storage

Eine Speicherlösung, die eine Kombination zwischen NAS und SAN darstellt,wird oftmals unter der Bezeichnung Hybrid-Storage oder kombinierte Spei-cherlösung (Unified Storage) geführt.

Der interne Aufbau solcher Systeme erfüllt alle Kriterien eines SANs. Nachaußen können sie jedoch sowohl als NAS als auch als SAN betrieben werden.Dieser Mischbetrieb wird durch den Einsatz entsprechender Systemkompo-nenten und eine entsprechende Konfiguration ermöglicht. So kann sich einSpeichersystem sowohl für einige Anwendungen per Ethernet-Anschluss als"Filer" präsentieren und somit Fileservices über CIFS und NFS zur Verfügungstellen als auch für andere Server per Fibre Channel oder iSCSI Speicherka-pazität zugänglich machen.

In der Praxis können NAS- und Storage-Controller entweder in einem IT-Sy-stem zusammengefasst werden oder als physisch getrennte Komponentenvorliegen. Neben klassischen Fibre-Channel-SAN-Switchen können auch so-genannte Converged oder Unified Switches zum Einsatz kommen, die nebenFC auch Fibre Channel over Ethernet (FCoE) und IP bedienen.

Abbildung 3: Schematische Dar-stellung eines Hybrid-Storage

Objekt-Storage

Objekt-Storage (oftmals auch als "Object-based Storage" bezeichnet) ermög-licht gegenüber den traditionellen blockbasierten und filebasierten Zugriffsme-thoden einen objektbasierten Zugriff.

Objektbasierende Speicherlösungen speichern Daten in Verbindung mit denzugehörigen Metadaten auf einem Datenträger in Form von Objekten und nichtin Form von Dateien. Mittels der Vergabe einer eindeutigen Objekt-ID (Hash-Wert), die in den Metadaten des Objekts festgehalten wird, kann das Objekteindeutig identifiziert werden. Der Zugriff auf einen objektbasierenden Spei-cher erfolgt über eine führende Anwendung. Die Anwendung greift hierbei übereine spezielle API und deren mögliche Kommandos oder direkt per IP auf den



Objekt-Storage zu. Im Falle eines Zugriffs per API muss die führende Applika-tion die herstellerspezifische API des gewählten Objekt-Storage unterstützen.

Objekt-Storage wird vor allem im Bereich Archivierung, Dokumentenmanage-ment und beim Ablegen von Objekten in einer Cloud eingesetzt.

Cloud-Storage

Im Zusammenhang mit Weiterentwicklungen im Storageumfeld etabliert sichzunehmend auch der Begriff des Cloud-Storage. Hierunter ist Storage für dieCloud-Nutzung zu verstehen. Die Speicherlösung an sich bleibt dabei weitge-hend unverändert, jedoch liegt eine von klassischen SAN- oder NAS-Architek-turen abweichende Art des Zugriffs auf die gespeicherten Daten vor. Dieserwird in der Regel mittels Web-Services realisiert.

Prüffragen:

- Sind bei der Planung der Speicherlösung die Möglichkeiten und Grenzender verschiedenen Arten von Speicherlösungen für die Verantwortlichender Institution transparent gemacht worden?

- Sind die Entscheidungskriterien für die Auswahl einer geeignetenSpeicherlösung nachvollziehbar dokumentiert worden?

- Ist die Entscheidung für die Auswahl der Speicherlösung nachvollziehbardokumentiert?



M 2.525 Erstellung einerSicherheitsrichtlinie fürSpeicherlösungen


Verantwortlich für Umsetzung: IT-Sicherheitsbeauftragter

Speicherlösungen als zentrale Instanz zur Datenspeicherung einzusetzen, istfür viele Abläufe und Geschäftsprozesse einer Institution essenziell. Der siche-re und ordnungsgemäße Betrieb kann nur sichergestellt werden, wenn Pla-nung, Stationierung, Administration und Betrieb von Speicherlösungen in diebestehenden sicherheitstechnischen Vorgaben integriert sind.

Die zentralen sicherheitstechnischen Anforderungen und das zu erreichendeSicherheitsniveau ergeben sich aus der organisationsweiten Sicherheitsleitli-nie. Die Anforderungen sollten in einer spezifischen Sicherheitsrichtlinie fürSpeicherlösungen formuliert werden, um die übergeordnete und allgemein for-mulierte Sicherheitsleitlinie im gegebenen Kontext zu konkretisieren und um-zusetzen.

Grundlage für eine angemessene Definition von Forderungen, die in derSicherheitsrichtlinie Ausdruck finden, ist die Dokumentation der Schutz-bedarfsfeststellung aller Daten, die in einer ausgewählten Speicherlösung(M 2.362 Auswahl einer geeigneten Speicherlösung) gespeichert werden sol-len. Nur hieraus lässt sich ableiten, welche Anforderungen an Verfügbarkeit,Integrität und Vertraulichkeit der Daten gestellt werden und entsprechend, wel-cher technische und organisatorische Aufwand angemessen ist.

Werden in einer Institution unterschiedliche Speicherlösungen (z. B. SAN,NAS, Objekt-Storage, Cloud Storage) eingesetzt, kann es sinnvoll für die Ver-antwortlichen sein, für die einzelnen Anwendungsfälle separate Sicherheits-richtlinien zu erstellen und sich dabei an der vorliegenden Maßnahme zu ori-entieren.

Da SAN-Lösungen ein dediziertes Netz enthalten, ist für die Erstellung einerSicherheitsrichtlinie für SAN-Lösungen zusätzlich die Maßnahme M 2.279 Er-stellung einer Sicherheitsrichtlinie für Router und Switches zu beachten. Dortwerden die allgemeinen Sicherheitsvorkehrungen für IT-Komponenten, die ineinem internen Netz den Zugang zu Informationen oder anderen Systemenermöglichen, vorgestellt. Für die Erstellung einer Sicherheitsrichtlinie für NAS-Lösungen ist zusätzlich die Maßnahme M 2.316 Festlegen einer Sicherheits-richtlinie für einen allgemeinen Server zu beachten. Dort werden die allgemei-nen Sicherheitsvorkehrungen für IT-Systeme mit einer Serverfunktion vorge-stellt. Sofern Cloud-Storage-Lösungen zum Einsatz kommen, sind zusätzlichdie Vorgaben aus M 2.535 Erstellung einer Sicherheitsrichtlinie für die Cloud-Nutzung aus dem Baustein B 1.17 Cloud-Nutzung zu betrachten.

Weitere Aspekte, die in der Sicherheitsrichtlinie für Speicherlösungen behan-delt werden müssen, sind:

Vorgaben für die Planung von Speichersystemen- Es sind Vorgaben für die technische Infrastruktur zu entwickeln, in der

Speicherkomponenten aufgestellt werden. Die Infrastruktur der Räume, indenen Komponenten der Speicherlösung stationiert werden, muss geeig-net sein, um die Verfügbarkeitsanforderungen der Speicherlösung durch



entsprechende Strom-, Netz- und Klimaversorgung zu erfüllen. Ebensosoll der Zutritt zu diesen Räumen angemessen geschützt werden.

- Es sind Vorgaben zu machen, die den Zugriff Externer (beispielsweisezu Wartungszwecken) regeln. Da Überwachungs- und Wartungsverträgevon Lieferanten der Speicherkomponenten oftmals direkte Anbindung derSpeicherlösung an Überwachungssysteme des Herstellers oder Lieferan-ten fordern, ist festzulegen, wie solche Zugriffe kontrolliert und protokolliertwerden.

- Wenn in Bezug auf die Verfügbarkeit ein sehr hoher Schutzbedarf festge-stellt wird, sollte der Einsatz einer desastertoleranten SAN-Lösung einge-fordert werden. Zu diesem Zweck sollte die Speicherlösung hinsichtlichSPoFs (Single Points of Failure), die bei einem Ausfall den Komplettaus-fall des Systems nach sich ziehen, analysiert werden. Ist eine sehr hoheVerfügbarkeit der Speicherlösung gefordert, ist die Analyse von SpoFs injedem Fall vorzunehmen. Sollen neue Komponenten in eine hochverfüg-bare SAN-Lösung eingebracht werden, ist deren reibungslose Integrationzunächst innerhalb spezieller Testsysteme zu überprüfen.

Vorgaben für die Arbeit von Administratoren- Es ist zu dokumentieren, nach welchem Schema Administrationsrechte für

einzelne Komponenten der Speicherlösung oder das Gesamtsystem ver-geben werden. Es ist empfehlenswert, ein entsprechendes Rollenkonzeptzu entwickeln.

- Es sollten Administrator-Rollen definiert werden, denen aufgabenbezogendie notwendigen Rechte eingeräumt werden. Insbesondere sollte die rou-tinemäßige Systemverwaltung (zum Beispiel Backup) nur mit den unbe-dingt notwendigen Rechten durchgeführt werden können. Die Administra-tor-Kennungen werden in der Folge den Rollen zugeordnet. Um die Aus-wirkungen von Fehlern zu reduzieren, darf unter einer Administrator-Ken-nung nur gearbeitet werden, wenn es zwingend notwendig ist.

- Der administrative Zugriff ist mindestens durch Einsatz starker Passwör-ter, gegebenenfalls auch durch besondere Maßnahmen zur Benutzerau-thentisierung abzusichern.

- Die Verwaltung und Kontrolle von Speicherressourcen durch die Admini-stratoren und der Zugriff für Revisoren auf die Systeme ist entweder nurlokal über eine direkt angeschlossene Konsole, ein eigenes Administrati-onsnetz oder über verschlüsselte Verbindungen zulässig. Der Zugriff aufSpeicherressourcen ist auf definierte Systeme zu beschränken und z. B.durch Sicherheitsgateways zu kontrollieren.

- IT-Systeme, die als Managementkonsole oder zur Revision eingesetztwerden, sind auf bestmögliche Weise vor Schadprogrammen zu schützen.

- Durch die vorgegebene Aufgabenteilung, durch Vorgaben und Regelun-gen und eine stets aktuelle Dokumentation der Einstellungen aller Spei-cherkomponenten ist sicherzustellen, dass Administratoren keine Aktio-nen ausführen oder Einstellungen an der Speicherlösung vornehmen, diezu Inkonsistenzen, Ausfällen oder Datenverlust führen können. RelevanteÄnderungen müssen dokumentiert werden. Es ist dazu empfehlenswert,ein Änderungsmanagement-Verfahren, z. B. in Anlehnung an ITIL (IT In-frastructure Library) zu betreiben.

- Es ist festzulegen, ob für bestimmte Änderungen das Vieraugenprinzipanzuwenden ist.

Vorgaben für die Installation und Konfiguration der Speicherlösung- Das Vorgehen bei der Erstinstallation ist zu dokumentieren. Da diese in

den meisten Fällen vom Hersteller oder Lieferanten vorgenommen wird,ist die entsprechende Dokumentation einzufordern.



- Nach der Installation sind die Default-Einstellungen in Bezug auf Sicher-heitsgefährdungen zu überprüfen, unsichere Dienste auf Netzkomponen-ten und Speichergeräten zu deaktivieren und die Standardkennungen und-passwörter zu ändern.

- Zugriffe von Systemkonsolen auf Speicherkomponenten über das LANsollten ausschließlich über verschlüsselte Verbindungen ermöglicht wer-den. Der Kreis der zugriffsberechtigten Anwender auf die Geräte ist mög-lichst klein zu halten. Regeln zur Verwendung und Konfiguration der Kon-sole und Restriktion der Zugriffsarten sind zu dokumentieren.

- Es ist zu regeln, wie Dokumentationen zu erstellen und zu pflegen sind undin welcher Form die Dokumentationen (z. B. Verfahrensanweisungen fürdie Einrichtung administrativer Kennungen, Betriebshandbücher für Ab-läufe und Kontrollen im Normalbetrieb) vorliegen sollen.

- Innerhalb des SANs sollten spezifische Methoden der Segmentierung (sie-he M 5.130 Absicherung des SANs durch Segmentierung) genutzt wer-den. Damit wird im SAN ein besserer Schutz von Teilbereichen sowohlbezüglich der Vertraulichkeit und Verfügbarkeit als auch bezüglich der In-tegrität der Konfiguration und der Verfügbarkeit des SANs erreicht.

Vorgaben für den sicheren Betrieb- Die Administration der Speicherlösung ist abzusichern, indem Zugriffe nur

über besondere Verbindungen (ein separates Administrationsnetz, gege-benenfalls auch das Speichernetz selbst) zugelassen werden.

- Es sind gegebenenfalls Werkzeuge auszuwählen, mit denen die Speicher-komponenten in einem bestehenden Netzmanagement betrieben, gewar-tet und integriert werden können. Vorgaben für eine sichere Konfigura-tion dieser Werkzeuge müssen definiert werden. Wenn möglich, solltennur verschlüsselte Verbindungen genutzt und nicht benötigte Schnittstel-len und Dienste deaktiviert bzw. gesperrt werden.

- Falls eine Fernwartung oder Überwachung durch den Hersteller genutztwerden soll, müssen Vorgaben für die Absicherung der Zugänge definiertwerden. Beispielsweise ist die Anbindung per VPN oder exklusiv genutz-te Verbindungen zu realisieren und eine für die Institution nachvollziehba-re Protokollierung dieser Aktivitäten einzufordern. Weitere Informationensind in der Maßnahme M 4.80 Sichere Zugriffsmechanismen bei Fernad-ministration enthalten.

- Es ist eindeutig festzulegen, wer berechtigt ist, Software-Updates zu initi-ieren oder Konfigurationen zu ändern. Die Vorgehensweise ist zu doku-mentieren. Sobald sehr hohe Anforderungen an die Verfügbarkeit beste-hen, ist zu fordern, dass Änderungen und Updates stets vor dem Wirkbe-trieb an baugleichen Testsystemen zu erproben und zu bewerten sind.

- Während des Betriebes einer Speicherlösung sind alle administrativen Tä-tigkeiten zu protokollieren. Darüber hinaus muss ein Konzept für die Ver-waltung und Überwachung der Speichersysteme erstellt werden. Informa-tionen zu diesem Thema finden sich in M 2.359 Überwachung und Ver-waltung von Speicherlösungen.

- In Abhängigkeit vom Schutzbedarf (z. B. hoch oder sehr hoch), vom Be-treibermodell (z. B. bei Fremdbetrieb), von der Lokation (z. B. Unterbrin-gung einzelner Komponenten oder der kompletten Speicherlösung bei ei-nem Dienstleister) oder in Abhängigkeit von der Mandantenfähigkeit be-steht die Notwendigkeit zum Einsatz von Verschlüsselung. Hinweise hier-zu finden sich in M 4.448 Einsatz von Verschlüsselung für Speicherlösun-gen.

- Die Regelungen für die Datensicherung der Speicherlösung sind mit demübergreifenden Datensicherungskonzept der Institution (siehe dazu Bau-stein B 1.4 Datensicherungskonzept) und mit den Schutzbedarfsanforde-rungen der Speicherlösung abzustimmen. Bei besonderen Anforderungen



an die Vertraulichkeit ist hier die Rechteverwaltung auf Backups vorzuge-ben.

- Aufgrund der zentralen Bedeutung einer Speicherlösung sind deren Not-fallvorsorge und die Pläne für den Notfall (siehe auch M 6.98 Notfallvor-sorge und Notfallreaktion für Speicherlösungen) in das organisationsweiteNotfallmanagement einzubinden.

- Verantwortlichkeiten und Vorgehen für Revision und Audit sind zu be-schreiben. Die Revision von Speicherlösungen ist in ein übergreifendesRevisionskonzept zu integrieren.

Prüffragen:

- Wurde eine Sicherheitsrichtlinie für den Betrieb von Speicherlösungenerstellt?

- Wurde ein Sicherheitsniveau in der Sicherheitsrichtlinie definiert?- Wurden in der Sicherheitsrichtlinie Vorgaben zur Planung, Administration,

Installation und Konfiguration sowie zum Betrieb von Speicherlösungenbeschrieben?

- Wann wurde die Sicherheitsrichtlinie zum letzten Mal aktualisiert?- Wurde die Sicherheitsrichtlinie für Speichersysteme in das

organisationsweite System für Revision und Audits aufgenommen undSchnittstellen zum Notfallmanagement geschaffen?



M 2.526 Planung des Betriebs derSpeicherlösung



Der dauerhafte sichere Betrieb einer Speicherlösung erfordert eine sorgfälti-ge Planung. Neben der Festlegung des Betreiberkonzeptes und des Aufstel-lungsortes der Speicherlösung muss der Betrieb der Speicherlösung organi-satorisch geregelt und dokumentiert werden. Zur Unterstützung des Betriebessollte ein Betriebshandbuch erstellt und regelmäßig aktualisiert werden.

Die wesentlichen Themen für die Planung des Betriebs der Speicherlösungsind im Folgenden ausführlich beschrieben.

Auswahl eines Betreiberkonzeptes

Die Entscheidung für ein Betreiberkonzept ist in der Regel bereits im Rahmender Planung der Speicherlösung gefallen. Für den Betrieb der Speicherlösungwerden hierzu nähere Angaben, beispielsweise hinsichtlich der verantwortli-chen Ansprechpartner, benötigt. Daher ist durch die Institution zu dokumen-tieren, ob der Betrieb der Speicherlösung durch eigenes Personal oder durcheinen Dienstleister mit oder ohne Übergabe der Betriebsverantwortung erfol-gen wird.

Angaben zum ausgewählten Dienstleister, zu den verantwortlichen Ansprech-partnern und möglichen Besonderheiten beispielsweise bei der Entscheidungfür die Nutzung von Storage as a Service (SaaS) sind ebenfalls zu dokumen-tieren.

Aufstellung der Speicherlösung

Die notwendigen Maßnahmen hinsichtlich der Aufstellung der Speicherlösungsollten ebenfalls bereits im Rahmen der Planung einer Speicherlösung be-trachtet werden. In der Regel stehen sie in engem Zusammenhang mit demgewählten Betreiberkonzept. Die Entscheidung hinsichtlich der Unterbringungin eigenen Räumen oder bei einem Dienstleister ist schriftlich festzuhalten.

In M 2.351 Planung von Speicherlösungen wird eine Reihe wichtiger Aspek-te bezüglich der erforderlichen Infrastruktur für die einzusetzende Speicher-lösung dargestellt. Für die Planung des Betriebs der Speicherlösung ist dieEinhaltung dieser Vorgaben zu prüfen, und die Informationen hinsichtlich desgewählten Aufstellungsortes der Speicherlösung und möglicher Besonderhei-ten sind gegebenenfalls zu ergänzen.

Es ist sicherzustellen, dass die dokumentierten Maßnahmen zur Aufstellungder Speicherlösung nicht im Widerspruch zu M 1.59 Geeignete Aufstellungvon Speicher- und Archivsystemen stehen.

Erstellung und Pflege eines Betriebshandbuchs

Es ist ein Betriebshandbuch zu erstellen und zu pflegen, das alle relevantenInformationen im Zusammenhang mit dem Betrieb der Speicherlösung bein-haltet. Neben einem Überblick hinsichtlich Architektur und Schnittstellen derSpeicherlösung sollte das Betriebshandbuch Aufschluss über die notwendi-gen administrativen Schritte zur Installation und zur Aufnahme des tatsäch-lichen Betriebs enthalten. Darüber hinaus ist die Betriebsdokumentation im



Rahmen dieser Maßnahme auf Vollständigkeit der Vorgaben zum laufendenBetrieb, zur Unterbrechung des Betriebs, zur Überwachung der Speicherlö-sung und hinsichtlich der Archivierung und Löschung von Daten zu prüfen.Fehlende oder fehlerhafte Angaben sind zu ergänzen bzw. zu korrigieren.

Es ist festzuschreiben, dass die Administratoren zur Einhaltung der Vorgabendes Betriebshandbuchs verpflichtet sind und Abweichungen gesonderter Re-gelungen bedürfen. Das Betriebshandbuch ist regelmäßig, mindestens einmalim Jahr, zu aktualisieren,

In den Hilfsmitteln des IT-Grundschutzes findet sich ein Dokument, in demeine Mustergliederung zur Erstellung eines Betriebshandbuchs für eine Spei-cherlösung dargestellt ist.

Abgrenzung bzw. Definition der Verantwortungsbereiche

In Abhängigkeit vom gewählten Betreiberkonzept sind weitergehende Anga-ben zu erfolgten Abgrenzungen hinsichtlich des Leistungs- bzw. Funktions-umfangs der Speicherlösung schriftlich festzuhalten.

Darüber hinaus sind alle benötigten Verantwortungsbereiche zu definieren. Sosind beispielsweise Aussagen darüber zu treffen, wer im Fall einer Störungdes Betriebs verantwortlich ist, wie die Alarmierungskette aussieht und wel-che Reaktionszeiten in einem solchen Fall festgelegt sind. Die Kontaktdatender Ansprechpartner müssen den zuständigen Administratoren bekannt undzugänglich gemacht werden. Sie sollten in einem deutlich kürzeren Intervallals einmal im Jahr aktualisiert werden.

Weitere Angaben hierzu finden sich auch in M 2.356 Vertragsgestaltung mitDienstleistern für Speicherlösungen sowie in M 6.98 Notfallvorsorge und Not-fallreaktion für Speicherlösungen. Es ist sicherzustellen, dass die dokumen-tierten Abgrenzungen und definierten Verantwortungsbereiche nicht wider-sprüchlich sind.

Umsetzung der Mandantenfähigkeit des Betriebs

Maßnahme M 2.528 Planung der sicheren Trennung von Mandanten in Spei-cherlösungen beschreibt die vorhandenen Möglichkeiten zur Umsetzung derMandantenfähigkeit in Speicherlösungen.

Es ist sicherzustellen, dass im Rahmen der Planung des Betriebs der Spei-cherlösung dokumentiert wird, welche konkreten organisatorischen oder tech-nischen Maßnahmen die Institution zur Trennung unterschiedlicher Mandan-ten ergreift. Dabei ist darzustellen, ob die Mandantentrennung allein auf Net-zebene oder zusätzlich durch den Einsatz produktspezifischer Funktionen wiebeispielsweise mittels virtueller Fileserver (auch unter diversen Herstellerbe-zeichnungen wie vFiler, virtuelle Datamover etc. bekannt) umgesetzt wird.

Darüber hinaus wird eine Übersicht aller erfassten Rollen und der zugehörigenRechte benötigt. Diese Übersicht sollte regelmäßig auf ihre Aktualität überprüftwerden.

Integration der Speicherlösung in die vorhandene Umgebung

Es ist zu dokumentieren, wie die geplante Speicherlösung für den Betrieb indie vorhandene Umgebung integriert werden soll. Dazu sollte die Institutionzunächst alle benötigten Schnittstellen erfassen und entsprechend darstellen.Daneben sind Vorgaben zur notwendigen Erweiterung bzw. zum Austauschbestehender Komponenten und zur Anpassung bestehender Prozesse darzu-



stellen. Während der Planung des Betriebs der Speicherlösung sind veränder-te Anforderungen und Aufgaben für die Mitarbeiter zu identifizieren und denVerantwortlichen frühzeitig mitzuteilen. Im Rahmen der erforderlichen Maß-nahmen sind insbesondere die Vorgaben aus M 3.54 Schulung der Admini-stratoren des Speichersystems zu beachten.

Umgang mit Tests und Freigabe der Teile der Speicherlösung

Es sind Vorgaben zur Durchführung von Tests sowie zur Freigabe von Kom-ponenten der Speicherlösung und Steuerungssoftware zu machen und schrift-lich festzuhalten.

Dabei sind Regelungen hinsichtlich benötigter Wartungsfenster und bestehen-der vertraglicher Vereinbarungen zu beachten. Es ist festzulegen, unter wel-chen Bedingungen der Einsatz einer Testumgebung verpflichtend ist und wel-che Voraussetzungen für die Freigabe eines Systems erfüllt sein müssen.

Wird die Speicherlösung durch einen externen Dienstleister betrieben, sinddaneben die Vorgaben aus M 2.356 Vertragsgestaltung mit Dienstleistern fürSpeicherlösungen zu beachten.

Einsatz von Verschlüsselung

Für den Betrieb ist zu regeln, welche Aufgaben die Administratoren der Spei-cherlösung beim Einsatz von Verschlüsselung haben. Hierzu gehören z. B.die Verwaltung der Schlüssel, die Durchführung von Datensicherungen undinsbesondere auch die Wiederherstellung verschlüsselter Daten.

Bei Verschlüsselung der Informationen sind der Baustein B 1.7 Kryptokonzeptsowie die Maßnahme M 4.448 Einsatz von Verschlüsselung für Speicherlö-sungen zu beachten.

Prüffragen:

- Sind alle erforderlichen Regelungen, Anforderungen und Einstellungenzum Betrieb der Speicherlösung dokumentiert?

- Wann wurde die Betriebsdokumentation für die Speicherlösung das letzteMal aktualisiert?

- Sind die Auswahl und Festlegung des Betreibermodells sowie diezugehörigen Entscheidungskriterien nachvollziehbar dokumentiert?



M 2.527 Sicheres Löschen in SAN-Umgebungen


Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Werden die in einer Speicherlösung erfassten Daten nicht länger benötigt,müssen diese gelöscht werden. Institutionen finden im Baustein B 1.15 Lö-schen und Vernichten von Daten bereits eine Vielzahl relevanter Maßnahmenzum sicheren Löschen von Daten. Insbesondere M 2.431 Regelung der Vor-gehensweise für die Löschung oder Vernichtung von Informationen geht aufdie Problematik der selektiven Datenlöschung ein, die auch in modernen Spei-cherlösungen von Bedeutung ist.

Das sichere Löschen von Daten in SAN-Umgebungen stellt insbesondere beider Nutzung durch unterschiedliche Mandanten, wie sie beispielsweise beiCloud-Storage anzutreffen ist, eine besondere Herausforderung dar. Daher isthier die Umsetzung zusätzlicher Maßnahmen zu empfehlen.

Verfahren zum sicheren Löschen in SAN-Umgebungen müssen bei der Pla-nung von Notfalltests und -übungen von Speicherlösungen (siehe auch Maß-nahme M 6.98 Notfallvorsorge und Notfallreaktion für Speicherlösungen) be-achtet werden. Bei solchen Tests und Übungen werden in kurzer Zeit großeDatenmengen in vielen LUNs mit gegebenenfalls unterschiedlichem Schutz-bedarf erzeugt, die nach Abschluss des Tests wieder gelöscht werden müs-sen. Vergleichbares gilt, wenn bei einem Desaster-Fall LUNs kopiert wurdenund nach der Bewältigung des Desasters mehrfach vorliegen.

Grundsätzlich bestehen folgende Möglichkeiten zur Löschung von Daten inSAN-Umgebungen:

- Löschen einer logischen Festplatte in einem Speichersystem (LUN):Beim Löschen einer LUN werden die logischen Strukturen auf den zuge-hörigen Festplatten, RAID-Gruppen oder Festplattenpools aufgebrochen,somit wird die Kapazität der gelöschten LUN wieder freigegeben. Es wer-den keine physischen Blöcke "genullt", also mit "Pattern" überschrieben.Der Zugriff auf die Daten einer LUN aus Anwendungssicht ist in der Folgenicht mehr möglich, da eine gelöschte LUN mit den Bordmitteln eines Spei-chersystems nicht wiederhergestellt werden kann. Nach dem Löschen derLUN ist nicht mehr nachvollziehbar, welche Sektoren einer Speicherein-heit bzw. Festplatte der LUN in welcher Form zugeordnet waren, sodassAngreifer lediglich Zugriff auf Bit- oder Byteebene erhalten können, nichtaber auf zusammenhängende Datensätze. Das Wiederherstellen der Da-ten einer LUN ist extrem aufwendig und benötigt physischen Zugang zuden Speichermedien. Unter Umständen können Angreifer hierfür speziel-le forensische Werkzeuge einsetzen, mit deren Hilfe die logische Strukturdurchbrochen werden kann.

- Mehrfaches Überschreiben der Daten einer LUN:Ausgehend vom zugeordneten Server werden die Daten einer LUN (mehr-fach) mit festgelegten Daten oder "random Pattern" überschrieben. Jenach Anforderung zur Datenlöschung einer Institution ist ein zertifiziertesLöschen nach US-Standard DoD 5220-22.M möglich. Institutionen könnensich hierzu am Markt erhältlicher Software bedienen. Daneben kann dieDurchführung einer zertifizierten Löschung häufig in Form eines Servicesdurch den Hersteller der Speicherlösung beauftragt werden. Die auf dieseWeise überschriebenen Daten lassen sich im Anschluss nicht mehr wie-



derherstellen. Es gilt jedoch zu beachten, dass die zertifizierte Datenlö-schung auf LUN-Basis nur serverseitig sichergestellt werden kann, da dieSpeichersysteme an sich diese Möglichkeit nicht bieten. Beim Löschenvon Daten auf diese Weise entsteht eine erhöhte Schreibaktivität in ei-nem Teil der Speicherlösung, die auch von anderen Mandanten genutztwerden kann. Es ist beim Löschen darauf zu achten, dass dadurch kei-ne Daten anderer Mandanten beeinträchtigt werden und die vorgeseheneDienstgüte den anderen Mandanten weiterhin zur Verfügung steht. Fernersollte beachtet werden, dass in SAN-Umgebungen dieses Verfahren nichtunbedingt funktioniert, wenn beispielsweise verschiedene Platten für un-terschiedliche Aktivitätsmodi bereitstehen. Liegt eine LUN beispielsweisein dem Bereich, der für wenig Schreibaktivitäten vorgesehen ist, und wirddann durch mehrfaches Überschreiben eine hohe Aktivität erzeugt, kopie-ren solche SANs diese LUN in den Bereich für hohe Schreibaktivität. Dannwird nur diese neue LUN überschrieben, aber die Daten in dem Bereichfür geringere Schreibaktivität bleiben unüberschrieben.

- Löschen von Daten eines Speichersystems:Sollen die gesamten Daten eines Speichersystems mithilfe eines zertifi-zierten Verfahrens durch Überschreiben gelöscht werden, bieten Herstel-ler von Speicherlösungen dies häufig als Service an.

- Disk Retention:Wird im Wartungsvertrag mit dem Hersteller "Disk-Retention" vereinbart,verbleiben defekte Festplatten im Fehlerfall in der Institution und werdennicht an den Hersteller übergeben. Die Verantwortung für die sichere Lö-schung der Inhalte der Festplatten obliegt in der Folge der Institution. Inder Regel werden die defekten Festplatten durch die Institution physischzerstört. Disk Retention ist oft mit höheren Kosten verbunden, sollte aberauch schon bei normalem Schutzbedarf bezüglich Vertraulichkeit geprüftwerden.

Die dargestellten Verfahren zum Löschen von Daten in einem Speichersystemsind vielschichtig und komplex. Den Verantwortlichen einer Institution solltedaher bewusst sein, dass dem sicheren Löschen von Daten ein besonderesAugenmerk gewidmet werden muss.

Aufgrund der Funktionsweise moderner SAN-Umgebungen ist die Wiederher-stellung von Daten jedoch mit einem extrem hohen Aufwand verbunden, so-dass derzeit bei normalem Schutzbedarf das Löschen einer LUN als ausrei-chend sicher angesehen wird.

Das Überschreiben einer LUN unter Einbeziehung aller möglichen zugehö-rigen Speichersegmente sollte bei einem erhöhten Schutzbedarf hinsichtlichder Vertraulichkeit geprüft werden.

Wird eine Speicherlösung außer Betrieb genommen, so sind die Inhalte derMaßnahme M 2.361 Außerbetriebnahme von Speicherlösungen umzusetzen.

Prüffragen:

- Ist für das Speichersystem festgelegt, welche Informationen mit welchenVerfahren zu löschen sind?

- Ist in mandantenfähigen Speicherlösungen die Löschung der LUNssichergestellt, die einem bestimmten Mandanten zugeordnet sind?

- Werden bei der Löschung von Daten mit hohem Schutzbedarf diezugehörigen Speichersegmente einer LUN mehrfach überschrieben?



M 2.528 Planung der sicherenTrennung von Mandanten inSpeicherlösungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: IT-Sicherheitsbeauftragter, Leiter IT

Für viele Institutionen ist Mandantenfähigkeit eine wesentliche funktionale Ei-genschaft von Speicherlösungen. Sofern die Anforderung zur Trennung vonMandanten in Speicherlösungen vorhanden ist, sollten Institutionen daherMaßnahmen ergreifen, um diese sicher zu gestalten.

Im Hinblick auf die Planung eines Speichersystems ist grundsätzlich zu hinter-fragen, in welcher Form und in welchem Umfang die Mandantenfähigkeit (mul-ti-tenancy) bei Einsatz dieser Lösung bereits durch den Hersteller umgesetztist. Viele Anbieter von Speicherlösungen werben damit, dass die von ihnenangebotenen Produkte mandantenfähig sind. Nicht immer versteht ein Anbie-ter dabei allerdings unter Mandantenfähigkeit jene Funktionalität, die den An-forderungen der Institution entspricht.

Die Realisierung von Speicherlösungen, wie sie in typischen Serviceprovi-der-Umgebungen anzutreffen sind, bedingt beispielsweise, dass die Daten un-terschiedlicher Anwender über die Applikationsisolation hinaus sicher vonein-ander getrennt sind.

Es ist daher darauf zu achten, dass die Hersteller bei der technischen Reali-sierung der von ihnen angebotenen Mandantenfähigkeit zumindest eine dernachfolgend beschriebenen Varianten zur Verfügung stellen.

- Im Block-Storage-Umfeld muss die Trennung von Mandanten mithilfedes LUN Maskings sichergestellt werden können. Die Managementkom-ponente der Speicherlösung sollte entsprechende Konfigurationsmöglich-keiten zur Verfügung stellen.

- In Fileservice-Umgebungen sollte die Möglichkeit bestehen, mit virtuel-len Fileservern (auch unter diversen Herstellerbezeichnungen wie vFiler,virtuelle Datamover etc. bekannt) zu agieren. Diese bieten die Möglichkeit,jedem Mandanten einen eigenen Fileservice zuzuordnen. Virtuelle Fileser-ver bieten die Möglichkeit, als gekapselte Umgebung administriert zu wer-den. Für den Einsatz in hochverfügbaren Umgebungen können virtuelleFileserver in dieser Form mit all ihren Eigenschaften von einem Rechen-zentrum ins andere gespiegelt werden. So kann die sichere Trennung vonMandanten auch nach dem Ausfall einer Speicherlösung oder einzelnerKomponenten aufrechterhalten werden.

- Bei höherem Schutzbedarf sollte die Möglichkeit bestehen, Mandanten,also internen oder externen Anwendern, Speicherressourcen aus unter-schiedlichen sogenannten Speicher-Pools zur Verfügung zu stellen. Da-zu werden verschiedene, physisch voneinander getrennte, Speichermedi-en zu einem Speicher-Pool zusammengefasst. Ein Speichermedium darfdabei immer nur einem einzigen Pool zugewiesen werden. Die logischenFestplatten (LUNs), die aus einem solchen Pool generiert werden, dürfenin der Folge nur einem einzigen Mandanten zugeordnet werden. Der Zu-griff eines Mandanten auf die Speichermedien eines anderen Mandantenist damit nicht möglich.

Neben der Umsetzung der Mandantentrennung über Funktionen, die direktdurch die Speicherlösung zur Verfügung gestellt werden, besteht auch dieMöglichkeit, die sichere Trennung von Mandanten über Maßnahmen auf Net-



zebene vorzunehmen. Beim Einsatz von IP, iSCSI und FC-SAN kann die tech-nische Trennung von Mandanten über eine Segmentierung im Netz vorge-nommen werden.

- Im IP- und iSCSI-Umfeld kann dies durch physisch getrennte Netze oderauch durch die Einführung von VLANs sichergestellt werden. WeitereInformationen hierzu finden sich in M 5.77 Bildung von Teilnetzen undM 5.62 Geeignete logische Segmentierung.

- Im FC-Umfeld kommt meist nur ein zentrales redundantes Netz zum Ein-satz. Nur in Ausnahmefällen wird hier eine physische Trennung der Netzerealisiert. Die Separierung wird in Regel unter Zuhilfenahme von VSANsund Soft Zoning sichergestellt. Hard Zoning kommt üblicherweise heuteeher selten zum Einsatz, da die höhere Sicherheit, durch die feste Zuord-nung von Speichermedien an ein bestimmtes Netz, die in SAN-Umgebun-gen benötigte Flexibilität einschränkt. Weitere Informationen hierzu kön-nen M 5.130 Absicherung des SANs durch Segmentierung und M 4.447 Si-cherstellung der Integrität der SAN-Fabric entnommen werden.

- Zusätzliche Maßnahmen bei hohem Schutzbedarf:Besteht hoher Schutzbedarf, insbesondere hinsichtlich der Vertraulichkeit,ist zu empfehlen, die Einführung von Verschlüsselung und ein entspre-chendes Schlüsselmanagement zu prüfen. Verschlüsselung kann dabeiauf unterschiedlichen Ebenen eingeführt werden. Nähere Angaben hier-zu finden sich unter anderem in M 4.448 Einsatz von Verschlüsselung fürSpeicherlösungen.

Prüffragen:

- Sind die Anforderungen an die Mandantentrennung nachvollziehbardokumentiert?

- Erfüllen die eingesetzten Methoden zur Mandantentrennung diedokumentierten Anforderungen?

- Wird im Block-Storage-Umfeld LUN Masking zur Mandantentrennungeingesetzt?

- Wird beim Einsatz von virtuellen Fileservern jedem Mandanten eineigener Fileservice zugeordnet?

- Wird beim Einsatz von IP, iSCSI und FC-SAN eine Trennung derMandanten über eine Segmentierung im Netz vorgenommen?



M 2.529 Modellierung vonSpeicherlösungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, Leiter IT

Um eine angemessene Gesamtsicherheit für den IT-Betrieb zu erreichen,muss die gesamte Speicherlösung mit allen Speichersystemen systematischim Sicherheitskonzept der Institution berücksichtigt werden. In Bezug auf dieIT-Grundschutz-Vorgehensweise bedeutet dies insbesondere, dass alle Spei-cherlösungen in die Strukturanalyse und in die Modellierung einbezogen wer-den müssen.

Als Modellierung wird in der IT-Grundschutz-Vorgehensweise die Zuordnungvon Bausteinen zu den vorhandenen Zielobjekten (IT-Systeme, Anwendun-gen, Räume etc.) bezeichnet. Grundsätzlich sind zur Modellierung von Spei-cherlösungen die Hinweise in Kapitel 2.2 der IT-Grundschutz-Kataloge zu be-achten. Die Zuordnung der IT-Grundschutz-Bausteine richtet sich in erster Li-nie nach der Funktion des IT-Systems (Server, Client etc.), nach dem verwen-deten Betriebssystem (Unix, Windows etc.) und nach den darauf betriebenenApplikationen (Datenbank, Webserver etc.).

Aufgrund der teils hohen Komplexität moderner Speicherlösungen finden sichin der Folge einige zusätzliche Modellierungshinweise, die auf konkrete Um-setzungsvarianten eingehen.

Modellierung eines Network Attached Storage (NAS)

Network-Attached-Storage-Systeme ermöglichen über die Protokolle NFS(Network File System) oder CIFS (Common Internet File System) Zugriffe aufdie Speichersysteme. Der Hauptanwendungsfall eines NASs besteht darin,Fileserverdienste zur Verfügung zu stellen. Viele Anbieter verwenden deshalbden Begriff "Filer" für solche Systeme.

Für NAS-Lösungen ist daher auch zusätzlich der Baustein B 3.101 Allgemei-ner Server anzuwenden.

Modellierung eines Storage Area Network (SAN)

Storage Area Networks (SAN) werden in der Regel durch ein dediziertes Spei-chernetz zwischen Speichersystemen und angeschlossenen Servern oderEndgeräten geschaffen. SANs wurden für die serielle, sehr schnelle und kon-tinuierliche Übertragung großer Datenmengen konzipiert. Sie basieren heutefür hochverfügbare, hochperformante Installationen auf der Implementierungdes Fibre-Channel- oder IP-Protokolls (iSCSI).

Für SAN-Lösungen ist daher auch der Baustein B 4.1 Heterogene Netze anzu-wenden. Auf die Netzkomponenten des SANs (z. B. Fibre-Channel-Switches)ist zusätzlich der Baustein B 3.302 Router und Switches anzuwenden.

Modellierung von Hybrid-Storage- oder Unified-Storage-Lösungen

Eine Speicherlösung, die eine Mischform zwischen NAS und SAN darstellt,wird oftmals als Hybrid-Storage oder kombinierte Speicherlösung (Unified Sto-rage) bezeichnet. Nach außen können sie jedoch sowohl als NAS als auch alsSAN betrieben werden. Dieser Mischbetrieb wird durch den Einsatz entspre-chender Systemkomponenten und eine entsprechende Konfiguration ermög-licht. So kann sich ein Speichersystem sowohl für einige Anwendungen per



Ethernet-Anschluss als "Filer" präsentieren und somit Fileservices über CIFSund NFS zur Verfügung stellen als auch für andere Server per Fibre Channeloder iSCSI Speicherkapazität zugänglich machen.

Für die Mischform zwischen NAS und SAN sind daher die BausteineB 3.101 Allgemeiner Server und B 4.1 Heterogene Netze anzuwenden. Aufdie Netzkomponenten des SAN (z. B. Fibre-Channel-Switches) ist zusätzlichder Baustein B 3.302 Router und Switches anzuwenden.

Modellierung von Speichervirtualisierung

Mit dem Einsatz von Speichervirtualisierung wird dem Speichernetz eine neuevirtuelle Schicht hinzugefügt, die die Speicherbereitstellung von den physi-schen Gegebenheiten abkoppelt. Die Grundlage einer Speichervirtualisierungstellt die Virtualisierungs-Appliance dar. Sie ermöglicht die zentrale Verwal-tung aller Speicherbereiche.

Auf die Komponenten der Speichervirtualisierungslösung sind zusätzlich dieBausteine B 3.101 Allgemeiner Server und B 3.304 Virtualisierung anzuwen-den.

Modellierung von Objekt-Storage


Objektbasierende Speicherlösungen speichern Daten in Verbindung mit denzugehörigen Metadaten auf einem Speichersystem in Form von Objekten undnicht in Form von Dateien. Mittels der Vergabe einer eindeutigen Objekt-ID(Hash-Wert), die in den Metadaten des Objekts festgehalten wird, kann dasObjekt eindeutig identifiziert werden. Der Zugriff auf einen objektbasiertenSpeicher erfolgt über eine führende Anwendung. Die Anwendung greift hier-bei über eine spezielle API und deren mögliche Kommandos oder direkt perIP auf den Objekt-Storage zu. Im Falle eines Zugriffs per API muss die füh-rende Applikation die herstellerspezifische API des Objekt-Storage unterstüt-zen. Objekt-Storage wird typischerweise vor allem im Bereich Archivierung,Dokumentenmanagement und beim Ablegen von Objekten in einer Cloud ein-gesetzt.

Für objektbasierte Speicherlösungen sind daher auch zusätzlich die BausteineB 3.101 Allgemeiner Server und B 5.24 Web-Services anzuwenden.

Modellierung von Cloud-Storage

Im Zusammenhang mit Weiterentwicklungen im Speicherumfeld etabliert sichzunehmend auch der Begriff des Cloud Storage. Hierunter wird Speicher fürdie Cloud-Nutzung verstanden. Die Speicherlösung an sich bleibt dabei weit-gehend unverändert, jedoch liegt eine von den klassischen SAN- oder NAS-Architekturen abweichende Art des Zugriffs auf die gespeicherten Daten vor.Dieser wird in der Regel mittels Web-Services realisiert.

Eine besondere Herausforderung im Zusammenhang mit Cloud-Storage istdie Mandantenfähigkeit der Gesamtlösung.

Aus Anwendersicht sind daher zusätzlich die Bausteine B 1.17 Cloud-Nutzungund B 5.24 Web-Services (gegebenenfalls zusammen mit B 5.21 Webanwen-dungen) zu betrachten.



Aus Betreibersicht ist zusätzlich der Baustein B 5.23 Cloud Management rele-vant. Während die Funktionsweise und die relevanten Sicherheitsaspekte desStorage-Element-Managers im Baustein B 3.303 Speicherlösungen / CloudStorage betrachtet werden, behandelt der Baustein B 5.23 Cloud Managementdie Gesamt-Orchestrierung der Cloud. Da die reibungslose Kommunikationmit dem "Cloud Orchestrator" durch den Storage-Element-Manager sicherge-stellt wird, entsteht hier die Schnittstelle zum Baustein B 5.23 Cloud Manage-ment.

Weitere Hinweise zur Modellierung von Speicherlösungen

Neben den bereits erwähnten Bausteinen sind in Abhängigkeit von der Aus-gestaltung der Speicherlösung zusätzlich folgende Hinweise zu beachten:

Datensicherung

Für Datensicherungsgeräte, die an das Speichersystem angeschlossen sind,ist der Baustein B 1.12 Archivierung zu betrachten. Konzeptionelle Aspekteder Datensicherung werden im Baustein B 1.4 Datensicherungskonzept erläu-tert.

Management von Speicherlösungen

Die Element-Manager von Speicherlösungen oder deren Komponenten stel-len in der Regel das zentrale Verwaltungswerkzeug dar, das mithilfe unter-schiedlicher Protokolle das Management der Speicherlösung bzw. der zuge-hörigen Komponenten steuert. Die Funktion und der Aufbau von Element-Ma-nagern unterscheidet sich nicht wesentlich von anderen Managementsyste-men. Diese lassen sich daher mit den vorhandenen Bausteinen aus den IT-Grundschutz-Katalogen abbilden. Hierzu gehört insbesondere der BausteinB 4.2 Netz- und Systemmanagement sowie systemspezifische Bausteine wiez. B. B 3.101 Allgemeiner Server, B 3.102 Server unter Unix, B 3.108 WindowsServer 2003, B 5.7 Datenbanken und B 5.21 Webanwendungen.

Cloud Storage Gateways

"Cloud Storage Gateways" sind spezielle Applikationsserver, die eine Um-setzung von Cloud-Protokollen (Simple Object Access Protocol, SOAP undRepresentational State Transfer, REST) auf Storage basierende Protokolle(block- oder filebasierend) gewährleisten.

Sofern ein Cloud Storage Gateway eingesetzt wird, sollten die BausteineB 3.301 Sicherheitsgateway (Firewall) und B 5.24 Web-Services zur Anwen-dung kommen. Darüber hinaus sind die protokollspezifischen Gefährdungenbeim Übergang in SOAP/REST zu berücksichtigen.

Bei der Beschaffung und Implementierung von Cloud Storage Gateways istdarauf zu achten, dass diese nicht auf proprietären Standards basieren, son-dern mit gängigen Storageprotokollen umgehen können und sich somit ein-fach in die bestehende Anwendungsinfrastruktur einbinden lassen. Grund-sätzlich sind hier zwei mögliche Ausprägungen zu betrachten:

- Der Betreiber einer Speicherlösung möchte seinen Anwendern den Zugriffmittels SOAP bzw. REST ermöglichen, wobei die Schnittstelle der Spei-cherlösung diese Zugriffsmöglichkeit zur Verfügung stellt.

- Der Anwender möchte eine Cloud-Storage-Lösung verwenden, die ledig-lich SOAP bzw. REST als Zugriffsprotokoll verwendet. Da die Systemedes Anwenders jedoch NFS, FC oder iSCSI erwarten, kommt ein Cloud



Storage Gateway zum Einsatz, mit dessen Hilfe die Protokollumsetzungerfolgt.

Sofern Cloud Storage Gateways über Zusatzfunktionen wie Backup-Lösungenoder Verschlüsselung verfügen, sind weiterhin die erforderlichen Bausteineanzuwenden.

Maßnahmenkatalog Personal M 3.54 Bemerkungen


M 3.54 Schulung der Administratorendes Speichersystems



Ein Speichersystem ist die Instanz, die viele oder gar alle immateriellen Werteder Institution trägt. Zudem wird die Administration von Speichersystemen mitsteigender Funktionalität immer komplexer und erfordert stets aktuelle Kennt-nisse. Deswegen ist es unerlässlich, dass die Administratoren des Speicher-systems ausreichend geschult sind, damit sie in der Lage sind, Probleme auseigenem Handeln heraus zu vermeiden, technische Probleme rechtzeitig zuerkennen und die Funktionen und Sicherheitsmerkmale optimal zu nutzen.

In den Schulungen sollten ausreichende Kenntnisse zu den für die Einrichtungund den Betrieb der Komponenten des Speichersystems notwendigen Vorge-hensweisen, Werkzeugen und Techniken vermittelt werden. Über Kenntnisseder grundlegenden IT-Technik hinaus gilt dies auch für herstellerspezifischeAspekte zu einzelnen Produkten, die als Komponenten des Speichersystemseingesetzt werden. Das bedeutet, dass beim Einsatz von neuen Produkten dieAdministratoren speziell zu diesen Produkten nachgeschult werden müssen.

Für Schulungsmaßnahmen sollte bereits bei der Beschaffung von IT-Kompo-nenten ein ausreichendes Budget eingeplant werden und ein Schulungsplanfür Administratoren erstellt werden. Die Inhalte einer Schulung sollten die fol-genden Punkte umfassen:

- Grundlagen zu Speichersystemen und Speichernetzen

- Überblick über Netze und Protokolle- Aufbau von Massenspeichersystemen- Funktionsweise eines Storage Area Network (im Fall eines SAN-Ein-

satzes)- SAN-Switching (im Fall eines SAN-Einsatzes)- Datensicherung von Massenspeichern

- Einrichtung von Speichersystemen und Speichernetzen

- Zusammenbau und Verkabelung- Einrichtung und Konfiguration von Speichereinheiten, SAN- Swit-

ches und Backup-Geräten- Betrieb von Speichersystemen und Speichernetzen

- Management der Geräte, Software-Werkzeuge- Integration in Netzmanagementsysteme (NMS)- Protokollierung- Einstellung, Verwaltung und Sicherung der Konfiguration.

- Fehlerbehebung bei Speichersystemen und Speichernetzen

- Fehlerquellen und Ursachen- Mess- und Analysewerkzeuge- Teststrategien zur Fehlersuche

- Informationssicherheit bei Speichersystemen und Speichernetzen

- Grundlagen der Informationssicherheit sowie relevante Sicherheits-aspekte

- Virenschutz- Authentisierung, Autorisierung



- Kryptoverfahren und Anwendungen- Gefahrenquelle "Default-Einstellungen"- Vorsorgemaßnahmen, Reaktion und Analyse- Incident Handling- Disaster Recovery Maßnahmen

Auch wenn in einer Gruppe von Administratoren die Aufgaben so verteilt sind,dass jeder Administrator nur einen bestimmten Verantwortungsbereich hat, istes unverzichtbar, dass alle Administratoren ein allgemeines Grundwissen be-sitzen. Die individuellen Schwerpunkte können davon ausgehend gezielt aus-gebaut und gepflegt werden. Zu vielen Produkten gibt es von den Herstellernoder spezialisierten Anbietern hierfür ein umfangreiches Angebot an aufein-ander aufbauenden und individuell vertiefenden Seminaren. Das Angebot anqualifizierten Schulungen stellt ebenfalls ein Kriterium dar, das bei der Ent-scheidung für einen bestimmten Hersteller berücksichtigt werden sollte.

Prüffragen:

- Wurden die Administratoren für Planung und Betrieb von Speichernetzengeschult?



M 3.92 Grundlegende Begriffe beimEinsatz von Speicherlösungen



Die Geschäftsprozesse in Institutionen sind heutzutage größtenteils von In-formationstechnik durchdrungen. Wichtige Informationen wie beispielsweiseKommunikationsdaten, Verträge, Werbematerialien oder Konstruktionspläneliegen in vielen Fällen ausschließlich in digitaler Form vor. Für Unternehmenund Behörden sind diese Daten von großer Bedeutung. Entsprechend sind dieAnforderungen, die Institutionen an ihre Speicherlösung stellen, in der Vergan-genheit stetig gestiegen. Gleichzeitig erweitern neue Entwicklungen im Spei-cherumfeld die möglichen Einsatzszenarien, bringen aber gleichzeitig neueGefährdungen mit sich. Der sorgfältigen Planung kommt daher im Zusammen-hang mit dem Einsatz von Speicherlösungen eine wachsende Bedeutung zu.

Voraussetzung für eine erfolgreiche Planung ist unter anderem das gemein-same Verständnis aller Verantwortlichen über grundlegende Begriffe, wie siebeim Einsatz von Speicherlösungen benötigt werden. Nachfolgend finden sichdaher Ausführungen zu Begriffen aus dem Speicherumfeld, die alle relevan-ten Aspekte abdecken.

Speicherlösung

Eine Speicherlösung besteht aus einem oder mehreren Speichernetzen so-wie einem oder mehreren Speichersystemen. Der Begriff Speicherlösung be-schreibt somit die Gesamtheit aller Komponenten, die zum Speichern von Da-ten und deren Bereitstellung für die zugreifenden Systeme erforderlich sind.

Speichersystem

Die zentrale Instanz, die für andere Systeme Speicherplatz zur Verfügungstellt, wird als Speichersystem bezeichnet. Der Einsatz eines Speichersy-stems erlaubt den zeitgleichen Zugriff mehrerer Systeme (z. B. virtuelle undphysische Server, Clients, Appliances) auf den vorhandenen Speicherplatz.Ein Speichersystem besteht aus mehreren Komponenten, die in der Folge nä-her beschrieben sind.

Speichermedien

Ein Speichersystem beinhaltet ein oder mehrere Speichermedien, die dasSpeichern und spätere Abrufen von Daten ermöglichen. Speichermedien kön-nen dabei beispielsweise in elektronische Speichermedien (z. B. Flash-Spei-cher), magnetische Speichermedien (z. B. Festplatten oder Magnetbänder)oder optische Speichermedien (z. B. optische Bänder) unterteilt werden.

Speichergehäuse

Im Regelfall sind Speichermedien in einem separaten Speichergehäuse un-tergebracht. Bei kleineren Speichersystemen können die Speichermedien al-lerdings auch zusammen mit den Speicher-Controllern oder NAS-Controllernin einem gemeinsamen Gehäuse verbaut sein.



Speicher-Controller

Ein Speichersystem kann mit einem oder mehreren redundant ausgelegtenSpeicher-Controllern ausgestattet sein. Ein Speicher-Controller besteht dabeiin der Regel aus folgenden Komponenten:

- Frontend-Ports (Fibre Channel + Ethernet)- Speicherprozessor(en) und dazugehöriger RAM- Speicher-Cache- Backend-Ports zu den Speichergehäusen (SAS, FC)

Der Speicher-Controller ermöglicht die Konfiguration des Speichersystemsund stellt somit eine zentrale Komponente innerhalb des Speichersystems dar.Aufgabe des Speicher-Controllers ist darüber hinaus die Bereitstellung derkonfigurierten Speichermedien für das Speichernetz.

NAS-Controller

Ein Speichersystem kann mit einem oder mehreren redundant ausgelegtenNAS-Controllern ausgestattet sein. Der NAS-Controller ermöglicht unter Ver-wendung von NFS (Network File System) oder CIFS (Common Internet FileSystem) Zugriff auf die Speichersysteme. Der Hauptanwendungsfall bestehtdarin, Fileserverdienste zur Verfügung zu stellen. Der NAS-Controller kann ei-nerseits am Speicher-Controller angeschlossen sein, andererseits aber auchzusammen mit dem Speicher-Controller in einem Gehäuse untergebrachtsein.

Mögliche Zugriffsmethoden auf Speichersysteme

Speichersysteme lassen sich hinsichtlich ihrer Zugriffsmethoden unterschei-den. Nachfolgend sind gängige Varianten von Speichersystemen dargestellt.

- Blockbasierende Speichersysteme: Der Zugriff auf das Speichersystemerfolgt ausschließlich blockbasiert. Es wird kein NAS-Controller einge-setzt.

- Filebasierende Speichersysteme: Der Zugriff auf das Speichersystem er-folgt ausschließlich filebasiert. Es wird ein NAS-Controller eingesetzt.

- Unified Speichersysteme (file- und blockbasierend): Der Zugriff auf dasSpeichersystem erfolgt sowohl block- als auch filebasiert.

Speichernetz

Speichernetze ermöglichen einerseits den Zugriff auf die Speichersysteme,anderseits die Replikation von Daten zwischen Speichersystemen. Innerhalbeines Speichernetzes kommen unterschiedliche Protokolle zum Einsatz. Dar-über hinaus existieren, insbesondere bei blockbasiertem Zugriff, spezielleNetzkomponenten, die ein Speichernetz um spezifische Funktionen erweitern.

Protokolle

Der Zugriff auf Speichersysteme erfolgt mithilfe von Speichernetzen. Grund-sätzlich ist hierbei, wie bereits bei den Speichersystemen, zwischen IP-basier-tem Filezugriff (z. B. CIFS), IP-basiertem Blockzugriff (z. B. iSCSI) und reinblockbasiertem Zugriff (z. B. FC) zu unterscheiden. In Abhängigkeit der Zu-griffsform kommen jeweils unterschiedliche Protokolle zum Einsatz.

Bei einem IP-basierten Zugriff stehen folgende Protokolle zur Verfügung:

- NFS (Network File System)- CIFS (Common Internet File System), eine Erweiterung von SMB (Server

Message Block)



- HTTP (Hypertext Transfer Protocol)- WebDav (Web-based Distributed Authoring and Versioning)- REST (Representational State Transfer), ist eng mit HTTP verknüpft- SOAP (Simple Object Access Protocol)

Bei einem blockbasierten Zugriff stehen folgende Protokolle zur Verfügung:

- FC (Fibre Channel)- FCoE (Fibre Channel over Ethernet)- iSCSI (internet Small Computer System Interface)

Kommt iSCSI zum Einsatz, sollte hierfür ein separates Netz zur Verfügunggestellt werden. Damit liegt in der Folge eine Trennung hinsichtlich des Ad-ministrationsnetzes, des Produktionsnetzes für Anwendungen und Anwendersowie des iSCSI-Netzes vor. Dieses Vorgehen hat sich in der Praxis als BestPractice bewährt. Im Fehlerfall kann bei separaten Netzen die Ursache schnel-ler und einfacher gefunden bzw. behoben werden, zudem wirken sich Störun-gen lediglich auf ein Netz aus und nicht gleichzeitig auf alle Anwendungen.

Beim Ablegen von Objekten in einer Cloud wird häufig Objekt-Storage (oft-mals auch als "Object-based Storage" bezeichnet) eingesetzt. Objekt-Storageermöglicht gegenüber den traditionellen blockbasierten und IP-basierten Zu-griffsmethoden einen objektbasierten Zugriff. Dieser erfolgt direkt per IP oderper API und deren Kommandos über eine führende Anwendung.

FC-SAN-Switches

FC-SAN-Switches stellen bei einem FC-blockbasierten Zugriff für die zugrei-fenden Server die Verbindungsstelle ins Speichernetz dar. Sie ermöglichen inder Folge den gleichzeitigen Zugriff mehrerer Server auf die Speichersysteme.

Derzeit existieren folgende relevante Switch-Technologien:

- FC-SAN-Switches, die FC als einziges Protokoll nutzen- Unified-Fabric-Switches, die, je nach Konfiguration und Bestückung,

gleichzeitig als LAN-, FC- und FCoE-Switch dienen

Replikation

Unter Replikation ist die mehrfache Speicherung der Daten eines Speichersy-stems und die Synchronisation dieser Datenquellen zu verstehen. Eine Repli-kation kann dabei innerhalb eines Brandabschnitts, über Brandabschnitte hin-weg und sogar bis über die Grenzen von Rechenzentren oder Ländern hinauserfolgen. In der Praxis sind zwei Replikationsarten zu unterscheiden.

Die synchrone Replikation ermöglicht eine voll redundante Datenhaltung,bei der die Daten eines Speichersystems in Echtzeit auf ein entferntes Systemgespiegelt werden. Dabei wird sichergestellt, dass die Daten an den Stand-orten stets synchron gehalten werden. Von synchroner Replikation ist die Re-de, wenn eine Änderungsoperation an einem Datenobjekt nur dann erfolgreichabgeschlossen werden kann, wenn sie auch auf den Replikaten durchgeführtwurde (Quittierung).

Der Vorteil einer synchronen Replikation ist, dass die beiden Datenblöcke je-derzeit vollständig synchronisiert sind. Ein zuverlässiges Netz und vor allemniedrige Latenzzeiten sind die Voraussetzung für eine synchrone Replikation.Dies bedeutet, dass die Übertragungsreichweite beim Einsatz dieser Techno-logie begrenzt ist. Die Begrenzung ergibt sich hierbei entweder durch Spe-zifikationen der Hersteller oder basiert auf einer maximalen herstellerspezifi-schen Latenzzeit.



Bis zu einer Entfernung von 10 km stellt eine synchrone Datenspiegelung oh-ne Einsatz zusätzlicher Maßnahmen in der Regel kein Problem dar. Bei Ent-fernungen, die 10 km überschreiten, ist ein besonderes Augenmerk auf dieQualität der Datenverbindung zu legen. Bei Glasfaserverbindungen über 10km sind in den Fibre-Channel-Switchen anstelle der Short-Wave-Port-ModuleLong-Wave-Port-Module zu verwenden. Bei der Kopplung von Rechenzentrenmit Entfernungen über 10 km werden auch Technologien wie DWDM (DenseWavelength Division Multiplexing) oder CWDM (Coarse Wavelength DivisionMultiplexing) eingesetzt. Hier ist die absolute Latenz der Verbindungsstreckeausschlaggebend dafür, ob eine synchrone Spiegelung realisiert werden kann.

Im Gegensatz zur synchronen Replikation werden die Daten bei einer asyn-chronen Replikation nicht in Echtzeit, sondern zeitlich versetzt repliziert.Asynchrone Replikationen werden häufig bei IP-Anbindungen zwischen denStandorten eingesetzt. Die Übertragungsreichweite kann sich in diesem Fallauch über Kontinente hinweg erstrecken.

Speichervirtualisierung

Mit dem Einsatz von Speichervirtualisierung wird dem Speichernetz eine neuevirtuelle Schicht hinzugefügt, welche die Speicherbereitstellung von den physi-schen Gegebenheiten abkoppelt. Der Einsatz von Speichervirtualisierung bie-tet einer Institution eine Reihe von Mehrwerten:

- Erhöhte Flexibilität bei Aufbau, Planung und Erweiterung einer Speicher-lösung

- Vereinheitlichung des Speichermanagements- Unabhängigkeit bei der Auswahl der Speichersysteme

In der Praxis häufig anzutreffende Ausprägungen von Speicherlösungen

Network Attached Storage (NAS)

Network-Attached-Storage-Systeme bestehen in der Regel aus mindestenseinem NAS-Controller und einem oder mehreren Speichergehäusen. DerHauptanwendungsfall eines NAS besteht darin, den angeschlossenen Ser-vern über ein IP-Netz Fileserverdienste zur Verfügung zu stellen. Viele Anbie-ter verwenden deshalb den Begriff "Filer" für solche Systeme.

Storage Area Network (SAN)

Storage Area Networks werden in der Regel durch ein dediziertes Speicher-netz zwischen Speichersystemen und angeschlossenen Servern oder End-geräten geschaffen. SANs wurden für die serielle, sehr schnelle und kontinu-ierliche Übertragung großer Datenmengen konzipiert. Sie basieren heute fürhochverfügbare, hochperformante Installationen auf der Implementierung desFibre-Channel- oder IP-Protokolls.

Hybrid-Storage oder Unified Storage

Eine Speicherlösung, die eine Mischform zwischen NAS und SAN darstellt,wird oftmals unter der Bezeichnung "Hybrid-Storage" oder kombinierte Spei-cherlösung (Unified Storage) geführt. Nach außen können sie jedoch sowohlals NAS als auch als SAN betrieben werden. Dieser Mischbetrieb wird durchden Einsatz entsprechender Systemkomponenten und eine entsprechendeKonfiguration ermöglicht.

So kann sich ein Speichersystem sowohl für einige Anwendungen per Ether-net-Anschluss als "Filer" präsentieren und somit Fileservices über CIFS und



NFS zur Verfügung stellen als auch für andere Server Speicherkapazität perFibre Channel oder iSCSI zugänglich machen.

Objekt-Storage


Objektbasierte Speicherlösungen speichern Daten in Verbindung mit den zu-gehörigen Metadaten auf einem Datenträger in Form von Objekten und nichtin Form von Dateien. Mittels der Vergabe einer eindeutigen Objekt-ID (Hash-Wert), die in den Metadaten des Objekts festgehalten wird, kann das Objekteindeutig identifiziert werden. Der Zugriff auf einen objektbasierten Speichererfolgt über eine führende Anwendung. Die Anwendung greift hierbei über einespezielle API (IP) und deren mögliche Kommandos oder direkt per IP auf denObjekt-Storage zu. Im Falle eines Zugriffs per API muss die führende Applikati-on die herstellerspezifische API des Objekt-Storage unterstützen. Objekt-Sto-rage wird vor allem im Bereich Archivierung, Dokumentenmanagement undbeim Ablegen von Objekten in einer Cloud eingesetzt.

Cloud Storage

Im Zusammenhang mit Weiterentwicklungen im Speicherumfeld etabliert sichzunehmend auch der Begriff des Cloud Storage. Hierunter ist Speicher für dieCloud-Nutzung zu verstehen. Die Speicherlösung an sich bleibt dabei weit-gehend unverändert, jedoch liegt eine von den klassischen SAN- oder NAS-Architekturen abweichende Art des Zugriffs auf die gespeicherten Daten vor.Dieser wird in der Regel mittels Web-Service-Schnittstelle (via REST undSOAP) realisiert.

Eine besondere Herausforderung im Zusammenhang mit Cloud-Storage istdie Mandantenfähigkeit der Gesamtlösung.

Maßnahmenkatalog Hard- und Software M 4.80 Bemerkungen


M 4.80 Sichere Zugriffsmechanismenbei Fernadministration


Einige aktive Netzkomponenten können über einen Netzzugriff fernadmini-striert oder überwacht werden. Der Zugriff erfolgt entweder über verbindungs-orientierte oder verbindungslose Protokolle. Hierzu gehören:

- Protokolle zur reinen Datenübertragung, beispielsweise um neue Firm-ware-Versionen oder Konfigurationsdateien zu übertragen, z. B. FTP,TFTP (von letzterem wird prinzipiell abgeraten) oder RCP (siehe auchM 6.52 Regelmäßige Sicherung der Konfigurationsdaten aktiver Netzkom-ponenten),

- Protokolle zur interaktiven Kommunikation, z. B. SSH,- Protokolle für das Netzmanagement, z. B. SNMP oder CMIP.

Bei allen Zugriffsarten ist dafür Sorge zu tragen, dass kein unautorisierter Zu-griff erfolgen kann.

Hierzu sind die Standardpasswörter bzw. Community-Namen der Netzkom-ponenten gegen sichere Passwörter bzw. Community-Namen auszutauschen(siehe M 4.82 Sichere Konfiguration der aktiven Netzkomponenten). Die Kopp-lung von Community-Namen und Passwort betrifft bei vielen aktiven Netzkom-ponenten die Protokolle FTP, Telnet, SNMP und CMIP. Einige Komponentenbieten auch die Möglichkeit, den Zugriff auf der Basis von MAC- oder IP-Adres-sen zu beschränken. Soweit möglich, sollte diese Option genutzt werden, umden Zugriff nur von dedizierten Managementstationen aus zu gestatten.

Protokolle zur Datenübertragung (TFTP, FTP, RCP) sollten nur von der Netz-komponente selbst initiiert werden können. Dies trifft insbesondere für nichtauthentisierende Protokolle wie TFTP zu. Für interaktive Kommunikationspro-tokolle (Telnet) sollte die Auto-Logout-Option der Netzkomponente aktiviertwerden.

Bei den meisten der genannten Protokolle ist zu beachten, dass die Übertra-gung der Passwörter bzw. Community-Namen im Klartext erfolgt, also prin-zipiell abgehört werden kann (siehe hierzu M 5.61 Geeignete physikalischeSegmentierung und M 5.62 Geeignete logische Segmentierung)

Beispiel: Die bei SNMP standardmäßig voreingestellten Community-Namen"public" und "private" sollten gegen andere Namen ausgetauscht werden.

Prüffragen:

- Ist bei allen Zugriffsarten der Fernadministration dafür gesorgt, dass keinZugriff von Unberechtigten erfolgen kann?

- Bei Verwendung von Komponenten, bei denen der Zugriff auf MAC oderIPAdressen beschränkt werden kann: Wird der Zugriff nur von dediziertenManagementstationen gestattet?

- Können Protokolle zur Datenübertragung nur von den Netzkomponentenselbst initiiert werden?



M 4.274 Sichere Grundkonfiguration vonSpeichersystemen


Sämtliche Konfigurationsarbeiten an Speichersystemen müssen entspre-chend der erstellten Sicherheitsrichtlinie (siehe M 2.525 Erstellung einerSicherheitsrichtlinie für Speicherlösungen) durchgeführt werden und wie inM 2.358 Dokumentation der Systemeinstellungen von Speichersystemen be-schrieben dokumentiert und kommentiert werden.

Betriebssystem

Speichersysteme, die als NAS-Systeme betrieben werden können, sind spe-zialisierte Server, die intern von einem Betriebssystem verwaltet werden. Die-ses Betriebssystem ist üblicherweise eine eingeschränkte und leistungsge-steigerte Version eines Standard-Betriebssystems.

Auch bei SAN-Systemen, die aus einer Vielzahl von Einzelkomponenten be-stehen können, werden gegebenenfalls einzelne Komponenten durch Stan-dard-nahe Systeme verwaltet.

Vor allem bei diesen Betriebssystemen aber auch bei herstellerspezifischen"unbekannten" Systemen muss vor Inbetriebnahme sichergestellt sein, dassein aktueller Stand aller Software- und Firmwarekomponenten hergestellt wird,um bestmögliche Stabilität des Systems und auch Schutz gegen Angriffe wiez. B. durch Schadprogramme sicherzustellen.

Grundkonfiguration

Bevor ein Speichersystem in die IT-Produktion integriert wird, muss eine siche-re Grundkonfiguration hergestellt werden. Viele Geräte werden vom Herstel-ler mit einer Default-Konfiguration ausgeliefert, die vor allem auf eine schnelleInbetriebnahme mit möglichst umfassender Funktionalität ausgerichtet ist undin der so gut wie keine Sicherheitsmechanismen aktiv sind. Daher muss dieÜberprüfung der Default-Einstellungen und die Grundkonfiguration offline, ineinem eigens dafür eingerichteten und besonders gesicherten Testnetz oderüber das Administrationsnetz, erfolgen.

Bei der Konfiguration muss beachtet werden, dass unter Umständen nicht je-des Administrations- oder Konfigurationswerkzeug (Konsole, Webschnittstel-le, externes Konfigurationsprogramm) alle relevanten Informationen anzeigt.

Daher ist es wichtig, anhand der vorhandenen Dokumentation nachzuvoll-ziehen, dass auch alle relevanten Einstellungen vorgenommen wurden. Esist wünschenswert, wenn Konfigurationswerkzeuge alle Konfigurationsschritteam Speichergerät mindestens in lokalen Logdateien, besser noch auf einemzentralen Logging-System auswertbar dokumentieren.

Es bietet sich an, die Grundkonfiguration in folgende Schritte zu unterteilen:

- Lokale Konfiguration: Überprüfung und Anpassung der Konfigurationspa-rameter, die sich auf das Gerät selbst beziehen (beispielsweise Einstel-lung von RAID-Levels, Zuordnung von Festplatten zu Volumes, Zuord-nung von Backup-Geräten zu Speichergeräten), Einstellungen zur Proto-kollierung, Einstellungen für Konsolenzugang etc.



- Netzkonfiguration: Überprüfung und Anpassung der Konfigurationspara-meter, die sich auf die Einbindung des Geräts in das lokale Netz, das Ad-ministrationsnetz und das Speichernetz beziehen. Dienste zur Administra-tion wie telnet, tftp, oder http, bei denen Anmeldung und alle Informationenim Klartext ausgetauscht werden, sollten durch die verschlüsselten Äqui-valente ssh, sftp und https ersetzt werden.

- Bei SAN-Systemen muss die interne Segmentierung des Netzes durch Zo-ning und Port-Binding vorgenommen werden. Den angeschlossenen Ser-vern sollten nur die tatsächlich benötigten Ressourcen des SAN zugeord-net werden.

- Die Administration der Speichersysteme sollte in die zentrale Rechtever-waltung eingebunden werden (z. B. Active Directory, LDAP, Radius,...).

Benutzerkonten und Passwörter

Die Möglichkeiten für die Einrichtung von Benutzern und Rollen und das Zu-weisen von Berechtigungen unterscheiden sich von Hersteller zu Herstellerteilweise erheblich. Daher ist es empfehlenswert, entsprechend dem vorgege-benen Rechte- und Rollenkonzept für die Administration der Speichergeräteein detailliertes Konzept für die jeweiligen Geräte zu erstellen.

Oft sind ein oder mehrere Administrationszugänge mit allgemein bekanntenStandardnamen und Passwort oder sogar ohne Passwort vorkonfiguriert. Aufeinschlägigen Internet-Seiten können Listen mit herstellerspezifischen Stan-dard-Accounts und Passwörtern heruntergeladen werden.

Bei der Inbetriebnahme des Geräts müssen diese Standard-Benutzerkonten,falls möglich, geändert werden. In jedem Fall müssen aber die Passwörter derStandard-Accounts geändert werden. Nicht benutzte Benutzerkonten müssendeaktiviert werden.

Entsprechend dem Rechte- und Rollenkonzept müssen anschließend die vor-gesehenen Benutzerkonten und -rollen eingerichtet werden.

Konfigurationsdateien müssen vor unbefugtem Zugriff besonders geschütztwerden. Auch wenn z. B. eine verschlüsselte Speicherung von Passwörternsichergestellt ist, müssen solche Dateien vor unberechtigtem Lesen geschütztwerden, da sie geschäftskritische Informationen enthalten und auch verschlüs-selte Passwörter häufig in recht kurzer Zeit durch passende Programme ent-schlüsselt werden könnten.

Passwortrichtlinien der Institution bezüglich Länge, Stärke und Änderungs-häufigkeit sind also unbedingt zu beachten.

Login-Banner

Jenseits des Administrationsnetzes sollten keinesfalls Login-Nachrichten ei-nes Speichersystems sichtbar werden. In diesen Login-Nachrichten sind oftInformationen (beispielsweise Modell- oder Versionsnummer, Software-

Release-Stand oder Patchlevel) enthalten, die einem potentiellen Angreifervon Nutzen sein können.

Sollte es sich nicht vermeiden lassen, dass auch im Intranet der Institutionein Login möglich ist, sollte die Standard-Loginnachricht durch eine angepas-ste Version ersetzt werden, die keine internen Informationen enthält. Die Mo-dell- und Versionsnummer des Geräts und die Version des Betriebssystemsdarf unter keinen Umständen vom Login-Banner verraten werden. Stattdes-



sen sollten folgende Informationen bei einer Anmeldung am Gerät angezeigtwerden:

- Jeglicher Zugriff darf nur durch autorisiertes Personal erfolgen.- Alle Arbeiten sind entsprechend der Sicherheitsrichtlinie durchzuführen.- Das Gerät ist in zentrale Kontrollmechanismen, wie beispielsweise in ein

Netzmanagementsystem (NMS) zur Protokollierung und Erkennung vonVerstößen gegen die Sicherheitsrichtlinie eingebunden.

- Verstöße gegen die Sicherheitsrichtlinie werden disziplinarisch / straf-rechtlich verfolgt.

Protokollierung

Die interne Protokollierung auf dem Speichersystem muss so konfiguriert wer-den, dass vor allem Informationen, die zur Früherkennung von Problemen be-nötigt werden, leicht sichtbar werden.

Das Speichersystem und die zur Administration und Protokollierung genutz-ten Rechner sollten durch Nutzung eines NTP-Servers zeitlich synchronisiertwerden.

Es ist generell ratsam, alle IT-Systeme der Institution per NTP auf eine ein-heitliche Zeit zu synchronisieren.

Schnittstellen

Nicht genutzte Schnittstellen auf Speichersystemen sind zu deaktivieren. Dasbedeutet, dass nicht genutzte Anschlüsse (z. B. eine serielle Schnittstelle zumAnschluss eines Terminals) nicht verkabelt und Dienste, die nicht genutzt wer-den sollen, explizit deaktiviert werden sollten.

Test der Konfiguration

Zum Abschluss des Testbetriebes sollten Standardsysteme und auch die Absi-cherung des Administrationsnetzes durch einen Sicherheitscheck geprüft wer-den.

Backup der Konfiguration

Die Konfigurationsdateien der Grundkonfiguration bilden die Basis für die wei-tere Konfiguration. Es müssen sowohl von der mit dem Gerät ausgeliefertenDefault-Konfiguration als auch von den Daten, die das Ergebnis der Grund-konfiguration darstellen, Sicherungskopien hergestellt und geschützt aufbe-wahrt werden.

Diese bilden die Grundlage für einen Wiederanlauf nach gravierenden Störun-gen (siehe M 6.98 Notfallvorsorge und Notfallreaktion für Speicherlösungen).

Prüffragen:

- Wurden alle Konfigurationsarbeiten gem. der Sicherheitsrichtlinie für dasSpeichersystem ausgeführt?

- Ist anhand der vorhandenen Dokumentation nachvollziehbar ob allerelevanten Einstellungen vorgenommen werden?

- Werden bei der Inbetriebnahme von Speichersystemen nicht benötigteBenutzerkonten deaktiviert, Standard-Passwörter im Einklang mit derPasswortrichtlinie geändert bzw. neue Accounts angelegt?

- Werden die vorgegebenen Benutzerkonten- bzw. -rollen entsprechenddes Rechte- und Rollenkonzepts eingerichtet?



- Ist die interne Protokollierung des Speichernetzes so konfiguriert, dassInformationen, die der Früherkennung von Problemen dienen, schnellerkannt werden?

- Sind nicht genutzte Schnittstellen des Speichersystems deaktiviert?- Speichersystem-Hardware: Werden die Default-Konfiguration, die

ermittelte Grundkonfiguration und die aktuelle Konfiguration redundantund geschützt aufbewahrt?



M 4.275 Sicherer Betrieb einerSpeicherlösung


Eine Speicherlösung läuft im Normalfall weitgehend autonom, ohne dass Ad-ministratoren eingreifen müssen. Zur Absicherung des Betriebs gibt es jedocheinige Maßnahmen, die ergriffen werden müssen, wenn die Funktionalität ei-ner Speicherlösung ohne Probleme dauerhaft und ohne Unterbrechung zurVerfügung stehen soll. Realisiert wird die Überwachung des Betriebs durchein Managementsystem (siehe M 2.359 Überwachung und Verwaltung vonSpeicherlösungen).

Überwachung- Anwendungen, Systemprogramme:

Es muss sichergestellt werden, dass Dienstprogramme störungsfrei lau-fen. Hierzu gehören z. B. die Antiviren-Software oder Scheduler, die au-tomatisierte Aufgaben wie die automatische Datensicherung steuern kön-nen.

- Kapazitätskontrolle und Systemauslastung:Es muss sichergestellt werden, dass Kapazitätsgrenzen von Speichersy-stemen nicht überschritten werden und Engpässe auf Speichersystemenoder im Speichernetz so rechtzeitig erkannt werden, dass Gegenmaßnah-men getroffen werden können.

- Überwachung kritischer Ereignisse:Es muss überwacht werden, dass sicherheitskritische Einstellungen nichtverändert und alle Sicherheitsvorgaben eingehalten werden. Ereignisse,die gegen wesentliche Sicherheitsregeln verstoßen, müssen unüberseh-bar gemeldet werden.

- Reduzieren der Systemnachrichten:Systemnachrichten sollten so reduziert werden, dass nur wirklich wichtigeNachrichten dargestellt werden.

Organisatorische Maßnahmen

Im Rahmen des sicheren Betriebs ist eine Unterscheidung hinsichtlich regel-mäßiger Aufgaben und anlassgesteuerter Aufgaben, wie sie beispielsweiseim Zusammenhang mit Sicherheitsvorfällen, dem Einspielen von Patches oderder Änderung von Berechtigungen auftreten, vorzunehmen.

Um Änderungen und Wartungsarbeiten an einer Speicherlösung durchführenzu können, die eine Betriebsunterbrechung zur Folge haben, sind im Rahmender Planung des Betriebs der Speicherlösung (M 2.526 Planung des Betriebsder Speicherlösung) Wartungsfenster zu definieren.

An einer laufenden Speicherlösung dürfen keine die Produktion beeinflussen-den Wartungsarbeiten und Änderungen außerhalb eines Wartungsfenstersdurchgeführt werden. Alle Änderungen, ob geplant oder ungeplant, müssenüber ein Änderungsmanagementverfahren mit allen beteiligten Fachverant-wortlichen abgestimmt werden. Der Änderungsplan sollte zur Nachvollzieh-barkeit archiviert werden.

Insbesondere Updates von Firmware oder Betriebssystem von Speichersyste-men und Netzkomponenten einer Speicherlösung dürfen nur innerhalb einesWartungsfensters durchgeführt werden.



Notwendige relevante Änderungen an der Konfiguration oder an interner Soft-ware der Speicherlösung müssen unbedingt aktuell dokumentiert werden. Die-se Dokumentation muss vor allem für die Behandlung von Störungen und inNotfallsituationen eindeutig und leicht verfügbar sein.

Insbesondere nach Änderungen der Systemkonfiguration sind die Logdateienvon Komponenten zur Datensicherung und Archivierung gesondert zu kontrol-lieren. Es sind außerplanmäßige Tests dahingehend vorzunehmen, ob Datenvom Backup wiederhergestellt werden können (siehe dazu auch M 6.22 Spo-radische Überprüfung auf Wiederherstellbarkeit von Datensicherungen).

Absicherung der Systemverwaltung

Das Managementsystem für die Speicherlösung ist selbst so abzusichern,dass ein Zugriff unberechtigter Anwender nicht möglich ist.

Prüffragen:

- Erfolgt eine Überwachung des Betriebs der Speicherlösung hinsichtlichder Verfügbarkeit der internen Anwendungen, der Systemauslastung undkritischer Ereignisse?

- Werden Änderungen nur über das Änderungsmanagement aktiviert?- Sind Wartungsfenster im Betrieb der Speicherlösung vorgesehen?- Werden Wartungsarbeiten, wie Updates, nur während der dafür

vorgesehenen Zeitfenster durchgeführt?



M 4.447 Sicherstellung der Integrität derSAN-Fabric


Integrität der SAN-Fabric bedeutet in dieser Maßnahme, dass lediglich die ge-planten und vom Betreiber vorgesehenen Komponenten in einer SAN-Fabricin Betrieb sind und nicht ein unachtsamer Mitarbeiter oder vorsätzlich han-delnder Angreifer Komponenten in die SAN-Fabric einbringt und dadurch dieSAN-Fabric im Betrieb stört oder einen Datenabfluss ermöglicht. Um die In-tegrität der SAN-Fabric sicherzustellen, sollten Protokolle mit zusätzlichen Si-cherheitsmerkmalen eingesetzt werden, die in dieser Maßnahme beschriebenwerden.

Das American National Standards Institute (ANSI) hat in diesem Zusammen-hang einen Standard entwickelt, der verschiedene Protokolle zur Erhöhungder Sicherheit in Fibre-Channel-Netzen beschreibt.

Fibre Channel Secure Protocol (FC-SP)

FC-SP beschreibt mögliche Architekturen für die sichere Authentisierung zwi-schen zwei Switches, Endgerät und Switch sowie zwischen zwei Endgeräten.Mithilfe der in FC-SPP beschriebenen Protokolle kann ein Switch neue End-geräte am SAN entweder lokal authentisieren oder über einen zentral instal-lierten Server, indem häufig auf eine bereits vorhandene Authentisierungsin-frastruktur zurückgegriffen wird.

Dem Anwender stehen drei verschiedene Protokolle zur Verfügung, mit derenHilfe sich Authentisierungsmechanismen in einem Fibre-Channel-SAN umset-zen lassen:

- Diffie Hellman Challenge Handshake Authentication Protocol (DH-CHAP):DH-CHAP bietet die bidirektionale, passwortbasierte Authentisierung(CHAP) zusätzlich gesichert per Diffie-Hellmann-Verfahren zum Schlüs-selaustausch.

- Fibre Channel Authentication Protocol (FCAP):FCAP realisiert die beiderseitige Authentisierung von FC-Komponentenauf der Basis digitaler Zertifikate.

- Fibre Channel Password Authentication Protocol (FCPAP):FCPAP stellt ein passwortbasiertes Verfahren dar, das sich das SecureRemote Password (SRP) zunutze macht.

Die Möglichkeiten dieser Protokolle sollten zur gegenseitigen Authentisierungder Komponenten genutzt werden. Durch den Einsatz dieser Protokolle kannsichergestellt werden, dass keine Komponenten der FC-Fabric beitreten kön-nen, ohne über die entsprechenden Zertifikate oder Passwörter zu verfügen.Die Konfiguration der Fabric kann damit weder gelesen noch manipuliert wer-den.

Selbst bei erfolgreichem physischen Anschluss fremder Komponenten an dieSAN-Fabric besteht in der Folge kein Zugang, der beispielsweise das Mitlesendes Datenverkehrs ermöglichen würde. WWN-Spoofing bleibt auf diesem Wegerfolglos.



Prüffragen:

- Wird die Sicherstellung der Integrität der SAN-Fabric durch den Einsatzvon Protokollen mit zusätzlichen Sicherheitsmerkmalen unterstützt?

- Werden beim Einsatz der Protokolle DH-CHAP, FCAP und FCPAPdie Sicherheitseigenschaften dieser Protokolle berücksichtigt undentsprechende Konfigurationen verwendet?



M 4.448 Einsatz von Verschlüsselung fürSpeicherlösungen


Für Informationen, die in einer Speicherlösung einen hohen Schutzbedarf be-züglich Vertraulichkeit aufweisen, sollten Möglichkeiten zum Einsatz von Ver-schlüsselung geprüft werden.

Werden Daten in Speicherlösungen verschlüsselt, müssen Institutionen wei-terhin die Maßnahmen M 2.46 Geeignetes Schlüsselmanagement sowieM 5.68 Einsatz von Verschlüsselungsverfahren zur Netzkommunikation be-achten und die notwendigen Vorgaben umsetzen.

Es ist zwischen der Verschlüsselung der Daten auf dem Transportweg (Da-ta-in-Motion) oder der Daten direkt auf der Speichereinheit (Data-at-Rest) zuunterscheiden. Die Verschlüsselung auf dem Transportweg ist auch bei Repli-kationen und Backup-Traffic relevant, während erstellte Backup- oder Archiv-daten at Rest zu verschlüsseln sind.

Die Verschlüsselung von Daten mit hohem oder sehr hohem Schutzbedarfbezüglich Vertraulichkeit sollte vorrangig durch die Anwendung sichergestelltwerden, die auch für die Verarbeitung der Daten zuständig ist.

Hierbei kann die Verschlüsselungstechnik entweder direkt in die Komponen-ten einer Speicherlösung integriert sein oder die Verschlüsselung mithilfe ei-nes zusätzlichen Produkts gewährleistet werden. Eine einfach umzusetzendeLösung bietet zum heutigen Stand der Einsatz von selbst verschlüsselndenFestplatten innerhalb eines Speichersystems.

Der Transport von Fibre-Channel-Frames sollte auch dann über eine ver-schlüsselte Verbindung erfolgen, wenn die Daten das Rechenzentrum nichtverlassen.

Die Sicherung einer SAN-Verbindung über IP erfordert die Umsetzung zusätz-licher Schutzmaßnahmen, da eine IP-Verbindung wesentlich leichter zu kom-promittieren ist als eine dedizierte Fibre-Channel-Verbindung. Stellt die An-wendung die Verschlüsselung der Verbindung nicht zur Verfügung, muss ei-ne verschlüsselte Verbindung auf anderem Weg (beispielsweise über Funk-tionen des Betriebssystems oder des Transportnetzes) herbeigeführt und ge-nutzt werden, um die Vertraulichkeit der Daten aufrechtzuerhalten.

Prüffragen:

- Erfolgt eine Verschlüsselung von Informationen mit hohem Schutzbedarf?- Ist festgelegt, auf welchen Ebenen (Data-in-Motion und Data-in-Rest) die

Verschlüsselung erfolgen soll?- Werden zusätzliche Schutzmaßnahmen zur Absicherung einer SAN-

Verbindung über IP umgesetzt?



M 4.449 Einführung einesZonenkonzeptes

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: IT-Sicherheitsbeauftragter, Leiter IT

Oft werden in Institutionen in der Regel große, aber einfache Netze aufgebaut,die ohne zusätzliche Sicherheitszonen auskommen. Dabei werden alle IT-Sy-steme einem einheitlichen Netz zugeordnet, an dessen Schnittstelle zum In-ternet eine zentrale Sicherheitsgateway-Lösung (siehe Baustein B 3.301 Si-cherheitsgateway (Firewall)) für die Informationssicherheit zuständig ist. Ei-ne solche einfache Sicherheitsarchitektur bietet jedoch gegen Angreifer oderSchadsoftware häufig ein zu geringes Maß an Sicherheit, da nach Überwin-dung des Sicherheitsgateways das gesamte Netz mit allen Komponenten undDaten offen steht.

Institutionen sollten angesichts dieser Gefährdung Maßnahmen ergreifen, umihr Netz und damit die angeschlossenen IT-Systeme wie beispielsweise Ser-ver, Clients, Netz (IP und FC) und Speicherkomponenten abzusichern. Als ei-ne mögliche Lösung bietet sich dabei die Bildung von Zonen an. Dazu wirddas Netz in separate Bereiche untergliedert, die jeweils beispielsweise durchein eigenes Sicherheitsgateway oder einen Paketfilter abgesichert werden.

Ein Zonenkonzept unterscheidet in der Folge verschiedene Sicherheitszonenmit unterschiedlichen Sicherheitseigenschaften. Die Einführung eines solchenZonenkonzeptes basiert auf der Feststellung des unterschiedlichen Schutzbe-darfs vorgehaltener Daten und bedarf zunächst sorgfältiger Planung.

Neben einer Schutzbedarfsanalyse sind alle derzeit im Netz vorhandenenKommunikationsbeziehungen zu ermitteln und mit den tatsächlich notwendi-gen Verbindungen abzugleichen. Dieses Vorgehen dient der Reduktion desNetzverkehrs auf ein sinnvolles und notwendiges Maß und der Minimierungder Abhängigkeiten zwischen IT-Systemen. Die ermittelten Daten bilden dieBasis für die Einteilung in Sicherheitszonen.

Sicherheitszonen unterscheiden sich dabei in der Regel durch:

- den Eigentümer der Prozesse und Daten,- die Klassifizierung und den Schutzbedarf der zu verarbeitenden Informa-

tionsobjekte,- die Benutzergruppen und Komponenten, die auf diese Informationsobjekte

zugreifen dürfen,- die Bedrohungen und die umgesetzten Sicherheitsmaßnahmen.

Alle eingesetzten IT-Systeme einer Institution werden genau einer Zone desZonenkonzeptes zugeordnet. Eine Sicherheitszone stellt für dieses System ei-ne Umgebung mit definierten Sicherheitseigenschaften bezüglich des Schut-zes der Kommunikationsbeziehungen zu anderen Zonen dar. Im Zusammen-spiel mit der Umsetzung eines Rechte- und Rollenkonzeptes, durch das Zu-griffe auf IT-Systeme in jeweils angrenzende Zonen erlaubt oder unterbundenwerden, können Daten mit einem höheren Schutzbedarf nach außen hin ab-gesichert werden.

Das Prinzip des Verbots zonenübergreifender Zugriffe sorgt dabei zusätzlichfür die Erhöhung des Sicherheitsniveaus, da es verhindert, dass Angreiferein kompromittiertes System mit weniger starken Sicherheitsmaßnahmen als"Sprungbrett" für das ganze Netz nutzen können. Wird ein IT-System kompro-mittiert, dann können lediglich die IT-Systeme aus der selben Zone angegrif-



fen werden. IT-Systeme anderer Zonen außerhalb der betroffenen Zone sinddurch die Maßnahmen zur Trennung der Zonen abgesichert.

Das Zonenkonzept formuliert das Sicherheitsniveau von Einsatzumgebungen,das durch eine konkrete Netz-, Anwendungs- und Sicherheitsarchitektur rea-lisiert werden muss. In Abhängigkeit vom Schutzbedarf der IT-Systeme sindunterschiedliche Ausprägungen möglich, die ein niedrigeres, mittleres oderhöheres Schutzniveau gewährleisten.

Prüffragen:

- Ist eine Analyse der bestehenden Kommunikationsbeziehungen innerhalbdes Netzes der Institution erfolgt?

- Wurde jedes IT-System einer einzigen Sicherheitszone zugeordnet?- Existiert eine Sicherheitsarchitektur, die Anforderungen an die

notwendigen Sicherheitsdienste und deren Schnittstellen für die einzelnenSicherheitszonen beschreibt?

Maßnahmenkatalog Kommunikation M 5.130 Bemerkungen


M 5.130 Absicherung des SANs durchSegmentierung

Verantwortlich für Initiierung: IT-SicherheitsbeauftragterVerantwortlich für Umsetzung: Administrator

Ein Storage Area Network (SAN) wird in der Regel durch ein dediziertes Spei-chernetz, häufig als Fibre-Channel (FC-SAN) realisiert, zwischen Speichersy-stemen und angeschlossenen Servern oder Endgeräten geschaffen. Ein odermehrere Switches, die miteinander verbunden sind, bilden dabei eine Fabric.An die Switches werden Server angeschlossen, denen Speicher aus den Res-sourcen des Speichersystems zugewiesen wird.

Speichersysteme, Server und deren Betriebssysteme können unabhängigvoneinander auch mehrfach zugeordnet werden. So werden einerseits ver-schiedenen Servern unterschiedliche (logische) Speicherressourcen auf ei-nem Speichersystem zugeordnet, andererseits können einem Server mehre-re (räumlich getrennte) Speichersysteme zugeordnet werden, um Redundanzfür den Server und damit dessen Anwendungen zu erreichen.

Demzufolge ist die Verwaltung und Rechtezuordnung der Speicherressourcenim SAN anzupassen. Es muss dabei sichergestellt werden, dass keine Datenaufgrund eines falschen Zugriffs zerstört werden und dass Server nur mit "ih-rem" Ausschnitt der Speichereinheiten im SAN arbeiten. Dies wird erreicht,indem das SAN in logische Segmente (VSANs) eingeteilt wird, sodass nur dieGeräte innerhalb eines Segmentes miteinander kommunizieren können.

Die Segmentierung bringt außerdem weitere Vorteile mit sich:

- Speicherkomponenten, die Interoperabilitätsprobleme miteinander auf-weisen, können so in getrennten Segmenten eingesetzt werden.

- Wichtige Anwendungen können einzelne Ports und damit eine bestimmteBandbreite (QoS - Quality of Service) zugewiesen bekommen.

- Zu schützende Daten können damit besser isoliert werden.- Verbesserung der Skalierbarkeit, da neue Endgeräte nicht auf Anhieb mit

allen anderen kommunizieren können.

Um eine sinnvolle Segmentierung sicherzustellen, sollte ein Konzept für dieZuordnung der SAN-Ressourcen erarbeitet werden. Die Informationen zur ak-tuellen Zuordnung der SAN-Ressourcen müssen stets dokumentiert und imNotfall verfügbar sein. Die aktuelle Ressourcenzuordnung sollte mithilfe derVerwaltungswerkzeuge einfach und übersichtlich erkennbar sein.

Segmentierung bei FC-SANs

Die interne Verwaltung und Zuordnung der Geräte in einem FC-SAN erfolgtüber World Wide Names (WWNs). Sie entsprechen in gewisser Weise denMAC-Adressen von Ethernet-Netzadaptern.

Die Segmentierung eines FC-SANs erfolgt durch Einteilung in VSANs und inZonen (Zoning). VSAN und Zoning-Funktionen werden auf den Switch-Kom-ponenten im SAN konfiguriert. Ein VSAN oder eine Zone kann Server, Spei-chersubsysteme und Switchports als Mitglieder beinhalten.

Die einzelnen Funktionen zur Segmentierung werden nachfolgend näher be-schrieben:



Zoning

Es wird zwischen Soft- und Hard-Zoning unterschieden. Soft-Zoning (WWN-Zoning) und Hard-Zoning (Port-Zoning) unterscheiden sich hinsichtlich ihrerAngriffsmöglichkeiten und hinsichtlich des Administrationsaufwands, der füreine sichere Konfiguration notwendig ist.

Soft-Zoning

SAN-Geräte (HBA-Port, Switchport etc.) haben einen eindeutigen World WideName. Beim Soft-Zoning werden Zonen durch die Gruppierung dieser eindeu-tigen WWNs gebildet. Die Zuordnung von Switchports und SAN-Geräten zuZonen erfolgt durch einen SAN-internen Namensserver. Wenn sich ein SAN-Gerät an der Fabric anmeldet, teilt der Namensserver nur WWNs von Gerätender gleichen Zone mit.

Administrationsaufwand:

- Die Vorteile des Soft-Zonings liegen im geringeren Administrationsauf-wand im Vergleich zum Hard-Zoning. Änderungen des Hardwarestandortsoder der Verkabelung müssen nicht berücksichtigt werden, da sie "mitwan-dern". Soft-Zoning ist damit insgesamt flexibler und dynamischer einsetz-bar, was vor allem in sich ändernden Umgebungen zum Tragen kommt.

Angriffsmöglichkeiten:

- Soft-Zoning ermöglicht es einem Angreifer, mittels WWN-Spoofing Zu-gang zu einer Kommunikationsgruppe und somit Zugriff auf die für dieseWWN freigegebenen Netzressourcen zu erlangen.

- Datenübertragungen zu gültigen WWNs werden nicht verhindert. MancheBetriebssysteme speichern WWNs intern und halten sie in einem Cachevor. Daher kann es vorkommen, dass ein solches System auf Speicher-geräte zugreift, die nach Willen des Administrators gar nicht mehr in derZone enthalten sind.

Das Risiko beim Einsatz von Soft-Zoning sollte, gerade bei besonders schutz-bedürftigen Daten, genau analysiert werden und entschieden werden, ob esfür die Institution tragbar ist oder nicht.

Hard-Zoning

Hard-Zoning wird über die feste Portzuordnung im SAN-Switch selbst reali-siert. Der Begriff Hard-Zoning begründet sich durch die feste Zuordnung vonphysischen Ports zueinander.

Hard-Zoning wird häufig auch als Port-Zoning bezeichnet. Die Segmentierungim SAN wird hergestellt, indem in Routingtabellen auf SAN-Switches Zonenausschließlich über die Portnummern der Switches gebildet werden. Dadurchsind genau die Geräte, deren Portnummern als eine Zone zusammengestelltsind, Mitglied dieser Zone. Diese statische Zuordnung erzwingt, dass kein Da-tenverkehr zwischen Ports unterschiedlicher Zonen stattfindet.

Administrationsaufwand:

- Änderungen der Hardwarekonfiguration oder Standortwechsel von SAN-Geräten erfordern eine manuelle Anpassung des Zonings, also der Zuord-nungstabellen. Die Umsetzung eines Hard-Zonings ist daher im Vergleichzum Soft-Zoning mit größerem administrativen Aufwand verbunden.



Angriffsmöglichkeiten:

- Hard-Zoning beugt dem WWN-Spoofing vor. Da hier die Kommunikationmithilfe der Ports definiert ist, können Angriffe mittels WWN-Spoofing nichtgelingen.

- Ein echtes Risiko beim Hard-Zoning besteht nur dann, wenn physischerZugang zum Switch besteht. In der Folge ist der Zugriff auf alle Netzres-sourcen ermöglicht, die für diesen Port freigegeben sind.

Da der physische Zugang zu Hardware für Unbefugte in der Regel nur schwerzu erlangen ist, wird das erreichbare Sicherheitsniveau durch Hard-Zoning alshöher angesehen als das durch Soft-Zoning realisierbare Sicherheitsniveau.Für Informationen mit höherem Schutzbedarf sollte daher Hard-Zoning zumEinsatz kommen. Die erhöhte Sicherheit sollte aber in einer sinnvollen Relati-on zum höheren Aufwand stehen.

Kombination von Hard- und Soft-Zoning

Die Kombination der beschriebenen Zoning-Verfahren erfolgt durch die Bil-dung von Zonen mittels Gruppierung eindeutiger WWNs bei gleichzeitiger Zu-ordnung spezifischer Portnummern der Switches zu einer solchen Gruppe. Sieermöglicht damit die Verhinderung der jeweiligen spezifischen Angriffsmög-lichkeiten.

Der damit einhergehende Administrationsaufwand erhöht sich entsprechendgegenüber dem getrennten Einsatz der Zoning-Varianten. Diese Variante wirddaher nur bei sehr hohem Schutzbedarf empfohlen bzw. auch für niedrigerenSchutzbedarf, wenn der Aufwand als gerechtfertigt gewertet wird.

LUN-Binding und -Masking

Speichersysteme in einem SAN stellen die eingebauten Platten als logischeEinheiten zur Verfügung. Diese können über ihre LUN (Logical Unit Number)adressiert werden. Um zu verhindern, dass jeder Rechner, der in einer Zonemit einem Speichersystem stationiert ist, alle logischen oder physischen Plat-ten dieses Systems sieht, werden LUN-Binding und LUN-Masking eingesetzt.

LUN-Binding ordnet die jeweiligen LUNs einer RAID-Gruppe oder einem Fest-plattenpool zu. Dazu werden Zugriffspfade zwischen adressierbaren Einhei-ten eines Speicherpools und den Fibre-Channel-Ports der Speichersystemedefiniert.

Bei LUN-Masking werden Zugriffstabellen auf dem Plattensubsystem definiert,in denen die eindeutigen WWN-Adressen der zugriffsberechtigten Server re-gistriert sind. Alle anderen (maskierten) Platten sind für den Server unsichtbar.

Auf diese Weise kann auch eine fehlerhafte Konfiguration oder Bedienungeines Rechners mit SAN-Anschluss nur noch Auswirkungen auf die für ihnsichtbar gemachten (maskierten) Platten (LUNs) haben.

Bei der Zuordnung von Ressourcen in Speichernetzen sollte stets eine Kom-bination aus Zoning, LUN-Binding und LUN-Masking zum Einsatz kommen.

Virtuelle SANs (VSANs)

Analog zur Segmentierung von LANs in virtuelle Teilnetze (VLANs) ist auchdie Segmentierung eines SANs in VSANs möglich. Dieses Konzept erweitertdas Konzept des Zonings und bietet sowohl einen besseren Zugriffsschutz auf



die Daten und Applikationen als auch Schutz vor einer breiteren Wirkung vonStörungen, die so auf einen Teil des Netzes begrenzt werden können.

In einem VSAN werden mehrere Ports und damit mehrere Endgeräte einerFibre-Channel-Fabric zu einer virtuellen Fabric, einem VSAN, zusammenge-fasst. Somit werden auf ein und derselben physischen Netzinfrastruktur meh-rere virtuell getrennte Fabrics eingerichtet. Ein Switch kann dabei mehrerenvirtuellen SAN-Teilnetzen angehören. Für jedes VSAN werden separate Fa-bric-Dienste wie Namensserver und Zoning realisiert. VSANs schränken al-so, über das reine Zoning hinaus, nicht nur die gegenseitige Sichtbarkeit vonEndgeräten, sondern auch die gegenseitige Sichtbarkeit der Fabric-Konfigu-rationen ein.

Zoning findet unabhängig von einer Trennung in VSANs statt. Eine Zone kannsich nicht über mehrere VSANs erstrecken.

Durch Zoning wird der Zugriff und Datenfluss zwischen den Geräten reguliert.VSANs erlauben zusätzlich, alle in einem Teilnetz bereitgestellten Dienste zuisolieren und innerhalb des VSANs "abzukapseln".

Wenn ausschließlich Zoning eingesetzt wird, bildet die gesamte Hardware desSpeichernetzes eine "Sicherheitsdomäne". Wenn auf der Netzhardware desSpeichernetzes VSANs konfiguriert werden, wird die Hardware logisch in ver-schiedene "Sicherheitsdomänen" aufgeteilt. Innerhalb dieser Domänen kön-nen dann "domäneninterne" Mechanismen wie Zoning (Hard- oder Soft-Zo-ning) eingesetzt werden.

Beim Einsatz von N-Port-IP-Virtualisierung (NPIV) ist darauf zu achten, dasseine eindeutige Zuordnung des World Wide Port Name (WWPN) zu einemServer erfolgt.

Segmentierung bei iSCSI

Die Segmentierung im iSCSI-Speichernetz erfolgt im Speichergerät analogzum Anschluss eines über FC-LUN angeschlossenen Gerätes. Der Unter-schied liegt in der Verbindungszuweisung zwischen dem Server und demSpeichergerät.

Der iSCSI-HBA (Host Bus Adapter) wird als "Initiator" und der Port am Spei-chergerät als "Target" bezeichnet. Über mitgelieferte Managementsoftwarewerden beide über ihre iSCSI-ID miteinander bekannt gemacht.

Um den Verbindungsaufbau abzusichern und die Authentizität von Initiator(Server) und Target (Festplatten) sicherzustellen, werden intern Sicherheits-protokolle wie CHAP (Challenge Handshake Authentication Protocol) oderiSNS (Internet Storage Naming Service) verwendet.

Die Zuordnung von LUNs zu den angeschlossenen Servern im Speichersy-stem erfolgt ähnlich dem LUN-Masking und LUN-Binding mit WWNs auf Basisder iSCSI-Initiator- und Target-ID. Bei Nutzung von iSCSI empfiehlt sich derEinsatz sogenannter Netzadapter mit TCP/IP Offload Engine (I/OAT). Dieseentlasten den Server von intensiven Rechenoperationen beim Auspacken dereigentlichen iSCSI-Daten aus den TCP/IP-Paketen.

Prüffragen:

- Existiert ein schriftlich fixiertes Konzept für die Zuordnung von SAN-Ressourcen zu Servern?



- Ist die aktuelle Zoning-Konfiguration dokumentiert und auch in Notfällenverfügbar?

- Ist die aktuelle Ressourcenzuordnung mithilfe vonVerwaltungswerkzeugen einfach und übersichtlich erkennbar?

- Wurde anhand der Sicherheitsanforderungen und desAdministrationsaufwands entschieden, welche Segmentierung in welchemSzenario zum Einsatz kommt?

Maßnahmenkatalog Notfallvorsorge M 6.1 Bemerkungen


M 6.1 Erstellung einer Übersicht überVerfügbarkeitsanforderungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Verantwortliche der einzelnen

Anwendungen

Für die in einem IT-System betriebenen IT-Anwendungen und deren Datensind die Verfügbarkeitsanforderungen festzustellen. Da eine IT-Anwendungnicht zwingend jeden Bestandteil des IT-Systems benötigt, sind die Verfügbar-keitsanforderungen der IT-Anwendungen auf die wesentlichen Komponentendes IT-Systems abzubilden. Das Ergebnis dieser Arbeit kann in Form einerÜbersicht mit folgenden Inhalten dargestellt werden:

IT-System IT-Komponente IT-Anwendung tolerierbare Aus-fallzeit

Zentralsystem Host Reisekosten 5 Arbeitstage

Buchhaltung 3 Stunden

DFÜ E-Mail 3 Arbeitstage

Buchhaltung 1 Arbeitstag

Drucker Reisekosten 10 Arbeitstage

Buchhaltung 2 Arbeitstage

Einsatzplanung 1 Arbeitstag

LAN Server Datenerfassung 1 Arbeitstag

Leitstelle 4 Stunden

PC Datenerfassung 10 Arbeitstage

PC Leitstelle 4 Stunden

(Lesart: Die IT-Komponente Host im IT-System "Zentralsystem" hat aufgrundder IT-Anwendung Buchhaltung eine maximal tolerierbare Ausfallzeit von 3Stunden.)

Eine praktikable Vorgehensweise ist es, zu den einzelnen IT-Anwendungenden Verfahrensverantwortlichen nach den tolerierbaren Ausfallzeiten der be-nutzten IT-Komponenten zu befragen, um danach die Ergebnisse nach IT-Sy-stem und Komponenten geordnet in der Tabelle aufzuführen.

Die Übersicht erleichtert es, die besonders zeitkritischen Komponenten desIT-Systems zu extrahieren, für die die Notfallvorsorge unumgänglich ist. BeiAusfall einer Komponente gibt diese Übersicht darüber hinaus Auskunft überdie betroffenen IT-Anwendungen und deren Verfügbarkeitsanforderungen.

Die Anforderungen an die Verfügbarkeit sind von den Anwendern bzw. Fach-abteilungen zu begründen, sofern dies nicht schon an anderer Stelle gesche-hen ist. Die Verfügbarkeitsanforderungen sind von der Behörden- bzw. Unter-nehmensleitung zu bestätigen.

Bei Ausfall einer Komponente des IT-Systems ermöglicht diese Übersicht ei-ne schnelle Aussage, ab wann ein Notfall vorliegt. Dass ein Notfall auch beiAusfall einer besonders zeitkritischen Komponente nicht zwingend eintretenmuss, lässt sich anhand eines Ersatzbeschaffungsplans und einer Untersu-chung über interne und externe Ausweichmöglichkeiten ermitteln.



Prüffragen:

- Sind für die in den ITSystemen betriebenen Anwendungen und derenDaten die Verfügbarkeitsanforderungen definiert?

- Existiert eine Dokumentation über die tolerierbaren Ausfallzeiten?



M 6.98 Notfallvorsorge undNotfallreaktion fürSpeicherlösungen


Um die Verfügbarkeit und Integrität der Speicherlösung sicherzustellen, sindumfassende Maßnahmen zur Notfallvorsorge erforderlich. Diese können zumeinen darin bestehen, rechtzeitig Fehler zu erkennen und zu behandeln undzum anderen aus den Anforderungen an den ordnungsgemäßen Betrieb re-sultieren. Darüber hinaus ist eine Dokumentation der Maßnahmen zur Notfall-vorsorge erforderlich, um im Notfall die angemessene Behandlung sicherstel-len zu können.

Fehlerbehandlung bei Speicherlösungen

In jedem IT-Betrieb treten Störungen auf, die vom sporadischen Fehlverhaltenvon Komponenten bis zum klar abzugrenzenden Ausfall eines Geräts reichenkönnen. Grundlage eines sicheren Betriebs ist die Vorbereitung auf solcheStörungssituationen. Hierzu gehören Ausfälle oder Beeinträchtigungen vonHardware und Software beispielsweise aufgrund von Defekten oder Kompro-mittierungen.

Um in derartigen Situationen effektiv und schnell reagieren zu können, müs-sen Diagnose und Fehlerbehebung bereits im Vorfeld geplant und vorberei-tet werden. Für typische und für bereits aufgetretene Ausfallszenarien solltenHandlungsanweisungen erstellt werden. Eine kochbuchartige Dokumentationvon Maßnahmen und Kommandos, die die Fehleranalyse und Fehlerkorrekturunterstützen, ist besonders hilfreich. Besteht in der Institution ein umfassen-des Notfallmanagement (siehe Baustein B 1.3 Notfallmanagement), sollte esVorlagen für solche Wiederherstellungspläne geben, die hier genutzt werdensollten. So kann sichergestellt werden, dass das Notfallteam alle Informatio-nen in geeigneter Form vorliegen hat.

Gerade bei komplexen Systemen wie einer Speicherlösung ist die Darstellungvon Verknüpfungen und Abhängigkeiten, die sich in jeder Institution individuellgestalten, entscheidend für die Beurteilung von Störungen und schnelles undzielgerichtetes Eingreifen.

Zu den Voraussetzungen für den Erfolg der Diagnosearbeiten gehört eine ge-eignete Protokollierung während des Betriebs (siehe auch M 2.359 Überwa-chung und Verwaltung von Speicherlösungen). Weiterhin sollten für die Feh-lerbehandlung geeignete Werkzeuge genutzt werden. Dazu existieren sowohlfrei verfügbare als auch kommerzielle Programme, oft auch vom Hersteller derSpeicherlösung und seiner Komponenten. Die Verwendung geeigneter Werk-zeuge ist umso wichtiger, da bei komplexen Lösungen nicht die Kontrolle undSteuerung der einzelnen Komponente, sondern die Übersicht über das Zu-sammenwirken von Hard- und Software der oftmals sehr heterogenen Ge-samtlösung gefordert ist.

Die Pläne, um Störungen zu behandeln, und auch das automatisierte Vorge-hen in einem Notfall (Umschwenken auf andere SANs, Replikationstests etc.)müssen getestet werden und sollten auch im Rahmen von Notfallübungen mit-geübt werden. Bei Notfalltests und Notfallübungen mit Speicherlösungen weistdie Nachbereitung eine Besonderheit auf, da durch Tests und Übungen große



Datenmengen erzeugt werden. Diese Daten können besonderen Schutzbe-darf bezüglich Vertraulichkeit aufweisen oder personenbezogene Daten ent-halten. Insbesondere in einem solchen Fall, aber auch bei normalem Schutz-bedarf müssen die Daten gemäß den Anforderungen nach Abschluss derÜbung sicher gelöscht werden (siehe Maßnahme M 2.527 Sicheres Löschenin SAN-Umgebungen). Der hierdurch notwendige zusätzliche Aufwand mussin der Planung dieser Tests und Übungen berücksichtigt werden. Auch dieWiederanlauf- und Wiederherstellungspläne müssen die Löschung überflüs-siger Daten, die im Rahmen der Bewältigung des Notfalls erzeugt wurden, mitberücksichtigen.

Es muss klar sein, dass gerade bei Speicherlösungen nach Störungen undNotfällen in Verbindung mit Datenverlust eine Rückführung in den Normal-betrieb nur dann möglich ist, wenn eine brauchbare Datensicherung bereit-steht. Eine Prüfung der Wiederherstellbarkeit von Datensicherungen (sieheM 6.22 Sporadische Überprüfung auf Wiederherstellbarkeit von Datensiche-rungen) muss regelmäßig durchgeführt werden.

Die Vorgehensweise bei der Fehlerbehandlung von Speicherlösungen lässtsich in die Bereiche Administration, Performancemessung und Diagnose un-terteilen. Nachfolgend werden die jeweils zu berücksichtigenden Aspekte dar-gestellt:

Administration

In einem Betriebshandbuch sollten alle notwendigen Kommandos zur Admi-nistration und Konfiguration dokumentiert werden.

Folgende Bereiche sind zu berücksichtigen:

- Einrichten von (administrativen) Benutzern, Vergabe von Berechtigungen- Update von Firmware und Betriebssystem- Konfiguration

- der Speicherressourcen- der administrativen Zugänge- der angeschlossenen Server und Sicherungsgeräte

- Protokollierung

Performance

Folgende Aspekte sollten für Beobachtungen und Aussagen über die Perfor-mance berücksichtigt werden:

- Belegung der Medien (pro logischem oder physischem Gerät)- Durchsatz pro Interface (IP, FC etc.), bezogen auf das Gesamtsystem- Statistikinformationen zur Nutzung

Diagnose

Alle für die Fehlerdiagnose ("Debugging") notwendigen Kommandos sowie diezu erwarteten Aussagen und ihre jeweilige Bedeutung sollten dokumentiertsein. Dazu zählen beispielsweise Aussagen über die Zustände der verschie-denen Systemkomponenten und Schnittstellen sowie über die aktuellen Kon-figurationen.

Unter anderem sind folgende Informationen für die Fehlerdiagnose relevant:

- Status der Netz-Interfaces und der sonstigen Anschlüsse- Status der Netzdienste (TCP/IP bei NAS-Systemen, spezifische Informa-

tionen beim SAN, z. B. Status der SAN-Switches)- Status zusätzlicher Komponenten (z. B. Storage-Virtualisierung)



- Gesamtkonfiguration als Überblick- Prozesse- Zuordnung- Angemeldete Benutzer- Protokollierung (Nutzung der Log-Level, Interpretation der Log-Informatio-

nen)

Notfallvorsorge zur Steigerung der Verfügbarkeit

Durch die Planung des Vorgehens bei Störungen kann die Zeit zur Wiederher-stellung minimiert und unter Umständen eine Lösung überhaupt erst ermög-licht werden. Die Planungen sind mit dem übergreifenden Notfallmanagementabzustimmen und sollten sich am allgemeinen Notfallkonzept orientieren (sie-he Baustein B 1.3 Notfallmanagement). In dem allgemeinen Notfallkonzeptwerden generelle Vorgaben für Notfalldokumente im gesamten IT-Betrieb for-muliert. Diese legen idealerweise einheitliche und verbindliche Anforderungenbeziehungsweise Aufbau, Inhalt und Form fest. Allerdings sollten bei dieserEingliederung in das allgemeine Notfallmanagement die Besonderheiten beider Notfallvorsorge und Notfallbehandlung von Speichersystemen nicht unbe-achtet bleiben. Die genauen Verfügbarkeitsanforderungen an die Speicherlö-sungen müssen klar definiert sein.

Folgende Fragestellungen sind für die Notfallvorsorge relevant:

- Was sind Gründe für mögliche Störungen?

- Hardwaredefekte- Zu geringe Dimensionierung (Störung oder Ausfall bei Steigerung

der Nutzung)- Welche Anforderungen bestehen an das Monitoring zur Vermeidung von

Notfällen?- Wie kann eine frühzeitige Störungserkennung sichergestellt werden?- Zusammenstellung der Informationen, die von den für den Betrieb der

Speicherlösungen verantwortlichen Stellen immer ausgewertet werden- Welche Vorsorgemaßnahmen können getroffen werden?

- Vorhalten von Ersatzgeräten- Vorhalten von Ersatzteilen- Umsetzung von Failover-Lösungen, die es ermöglichen, im laufen-

den Betrieb auf ein Alternativgerät umzuschalten.- Abschluss von Wartungsverträgen- Ausbildung der Mitarbeiter- Umsetzung von Maßnahmen zur Replikation- Verbindungen sind redundant auszulegen- Redundante Verbindungen über unterschiedliche Trassen- Unterschiedliche Carrier pro Verbindung- Ausreichende Dimensionierung von Leitungskapazitäten (Notfall)- Umsetzung von Maßnahmen zur Daten-Recovery- Erstellung eines Betriebshandbuchs- Erstellung eines Notfallplans- Aufrechterhaltung der Datenkonsistenz- Wird die Speicherlösung als Archiv genutzt, das nicht mehr gesichert

wird, muss mindestens eine zusätzliche Kopie jedes Objekts vorhan-den sein.

- Datenhaltung

- Für den Notfall ist im Betreiberkonzept festzuhalten, welche Datengespiegelt werden (redundant vorgehalten werden) bzw. welche Da-ten im Notfall aus dem vorhandenen Backup wiederhergestellt wer-



den müssen. Die Grundlage für diese Vorgehensweise ergibt sichaus den vorhandenen SLAs.

- Redundante Auslegung der IP- und FC-Netze- Redundante FC-Topologie unter Beachtung einer eineindeutigen

WWN Vergabe- Redundante LAN-Topologie unter Beachtung einer eineindeutigen

IP-Adressvergabe- Die Ausfallsicherheit von Segmentierung und Zoning ist durch red-

undante Auslegung der entsprechenden Netzkomponenten sicher-zustellen.

- Besonderheiten bei Cloud-Speicherlösungen

- Beim Einsatz von Cloud-Speicherlösungen ist darauf zu achten,dass die Orchestrierung ausfallsicher umzusetzen ist.

- Welche Service Level Agreements (SLAs) sollten getroffen werden?

- Hardwarelieferanten (beispielsweise Vor-Ort-Austausch mit Zeitga-rantie für bestimmte Komponenten)

- Verwaltung der Service Level Agreements: Es muss sichergestelltwerden, dass SLAs rechtzeitig verlängert werden beziehungsweiserechtzeitig an die aktuellen Anforderungen angepasst werden.

Weitere Hinweise zur Notfallvorsorge und Notfallreaktion, gerade wenn an dasSAN höherer Schutzbedarf bezüglich Verfügbarkeit besteht, sind im Hochver-fügbarkeitskompendium auf den Internetseiten des BSI zu finden.

Verwaltung von Service Level Agreements:

SLAs werden in der Regel für einen begrenzten Zeitraum abgeschlossen undnicht immer automatisch verlängert. Darüber hinaus passiert es häufig, dassdie Preise für die Verlängerung von SLAs für längere Zeiträume deutlich stei-gen oder dass diese für veraltete Systeme gar nicht mehr angeboten wer-den. In diesem Fall sollte geprüft werden, ob möglicherweise eine Investitionin neue Speichersysteme langfristig kostengünstiger ist. Dies muss rechtzeitigberücksichtigt und geplant werden.

Notfallvorsorge bei Cloud-Speicherlösungen

Bei der Nutzung von Cloud-Speicherlösungen sollte sich eine Institution be-reits bei der Auswahl eines Dienstleisters und der entsprechenden Vertragsge-staltung (M 2.356 Vertragsgestaltung mit Dienstleistern für Speicherlösungenund M 2.541 Vertragsgestaltung mit dem Cloud-Diensteanbieter) über Not-fallvorsorgemaßnahmen des Anbieters erkundigen. Bedingt durch das star-ke Abhängigkeitsverhältnis von Cloud-Serviceprovidern ist die Notfallvorsorgeallein aufseiten der nutzenden Institution nicht ausreichend. Weitere Hinweisezur Notfallvorsorge bei Cloud-Speicherlösungen finden sich unter anderem inM 6.155 Erstellung eines Notfallkonzeptes für einen Cloud Service.

Dokumentation zur Notfallvorsorge

Das genaue Vorgehen in bestimmten Notfallsituationen muss in einem Notfall-plan beschrieben werden. Das Vorgehen sollte folgende Punkte beinhalten:

- Wie ist eine Diagnose durchzuführen? Folgende Informationen können da-bei behilflich sein:

- Statusabfragen- Anzeige der Konfiguration- Anzeige der laufenden Prozesse- Angemeldete Benutzer



- Protokollierung- Welche Entstörungsprozeduren müssen durchgeführt werden?

- Vorgehen bei Ausfall der kompletten Speicherlösung (Wiederher-stellen von Betriebssystem und Konfiguration)

- Vorgehen bei Ausfall von Teilkomponenten, beispielsweise Festplat-ten

- Wer ist im Schadensfall zu benachrichtigen?

- Server- und Anwendungsadministration- Hardwarelieferant/Ansprechpartner für den Wartungsvertrag- Alle notwendigen Informationen zu den Wartungsverträgen und Ser-

vice Level Agreements, Hotline-Nummern, Kunden- oder Gerätei-dentifikationsnummern

- Welche Dokumente müssen im Schadensfall verfügbar sein?

- Wartungsverträge- Grundkonfiguration zur (Wieder-)Inbetriebnahme- Änderungen der Grundkonfiguration, um die aktuelle Betriebskonfi-

guration einzurichten- Regelwerk für die Zugriffskontrolle (Access Control Lists)- Eingerichtete Benutzer und Berechtigungen- Passwörter für Notfallzugriffe

- Wie verläuft der Wiederanlauf?

- Abhängigkeiten zu anderen Systemen des IT-Verbunds- Neuinstallation des Betriebssystems und Konfiguration- Zurückspielen einer gesicherten Konfiguration- Möglichkeiten eines eingeschränkten Betriebs- Remote-Betrieb an einem anderen Standort

Die für die Notfallvorsorge notwendigen Vorgehensbeschreibungen sind mög-lichst sorgfältig zu erstellen und regelmäßig zu erproben. Eventuell müssenvariierende Vorgehensweisen bei unterschiedlichen Gerätetypen und Betrie-bssystemen berücksichtigt werden.

Die Dokumentation sollte keinesfalls ausschließlich elektronisch vorliegen.Handlungsanweisungen sollten mindestens auch in Papierform existieren.Gegebenenfalls können Konfigurationsdateien auch auf einen externen Da-tenträger wie CD-ROM oder USB-Stick gesondert hinterlegt werden.

Die wahrscheinlich wichtigste Maßnahme zur Steigerung der Verfügbarkeit istdie Vorhaltung von Ersatzteilen, um bei Hardwaredefekten die Ausfallzeitenzu minimieren. Alternativ oder auch als Ergänzung hierzu können Wartungs-verträge mit dem Hersteller abgeschlossen werden, die durch garantierte Re-aktions- oder sogar Reparaturzeiten die Verfügbarkeit sicherstellen. Hierdurchlassen sich Kosten für die Lagerhaltung reduzieren oder eine noch höhereHardwareverfügbarkeit erreichen. Im Rahmen eines solchen Vertrages kannauch die Versorgung mit Software-Updates geregelt werden (Softwarewar-tung). Gegebenenfalls ist im Rahmen des allgemeinen Notfallmanagementsein gestaffelter Wiederanlauf für die Speicherlösung vorgesehen. In diesemFall wird erst ein Teil der Speicherlösung wieder in Betrieb genommen, sodassdie zeitkritischsten Geschäftsprozesse im nötigen Umfang eines Notbetriebslaufen können. In diesem Fall existieren neben den Wiederherstellungsplänenauch Wiederanlaufpläne, die den gleichen Anforderungen unterworfen sind,wie die Wiederherstellungspläne.

Durch den Einsatz von Speichervirtualisierung ergeben sich neue Möglichkei-ten zur Notfallvorsorge. So kann beispielsweise eine redundante Speicherung



auf verschiedenen Speichersystemen durch die Speichervirtualisierung (Dis-tributed LUN) gewährleistet werden. Auf diesem Weg wird ein Hot-Standbyder Speicherlösung realisiert, durch das Ausfallzeiten fast gänzlich vermiedenwerden können.

Prüffragen:

- Existieren Handlungsanweisungen in Form von Maßnahmen undKommandos, welche die Fehleranalyse und Fehlerkorrektur unterstützen?

- Werden für die Fehlerbehandlung geeignete Werkzeuge genutzt?- Existiert ein Notfallplan für die eingesetzten Speicherlösungen, der das

genaue Vorgehen in bestimmten Notfallsituationen beschreibt?- Werden die für die Notfallvorsorge notwendigen

Vorgehensbeschreibungen regelmäßig erprobt?- Werden bei den Tests und Übungen sowie im Notfall selbst hinterher die

überflüssigen Daten gemäß ihrem Schutzbedarf gelöscht?

Kreuzreferenztabelle für B 3.303

144

G 1.2 G 1.9 G 2.1 G 2.4 G 2.5 G 2.7 G 2.26 G 2.27 G 2.37 G 2.48 G 2.54 G 2.67 G 2.82 G 2.103 G 2.109 G 2.182 G 2.183 G 2.184 G 2.185 G 2.186 G 2.187 G 3.9 G 3.16 G 3.24 G 3.38 G 3.79 G 4.13 G 4.53M 1.59 UM A X X XM 2.351 PK A X X X XM 2.354 PK Z XM 2.355 BE C XM 2.356 BE C X X X XM 2.357 UM BM 2.358 UM A X XM 2.359 BT B X X XM 2.360 BT B X XM 2.361 AU C X XM 2.362 PK A XM 2.525 PK A X X X X X X X X XM 2.526 UM A X X X X X X XM 2.527 BT B X XM 2.528 PK Z X X XM 2.529 PK W XM 3.54 UM A X X X X X XM 3.92 PK W XM 4.80 UM B X XM 4.274 UM A X X X X X X X X XM 4.275 BT A X X X X X XM 4.447 BT Z XM 4.448 PK Z X XM 4.449 PK Z X XM 5.130 UM B XM 6.1 NV A XM 6.98 NV A X X

G 4.95 G 4.96 G 5.1 G 5.2 G 5.4 G 5.7 G 5.8 G 5.10 G 5.18 G 5.20 G 5.28 G 5.57 G 5.89 G 5.102 G 5.129 G 5.130 G 5.185 G 5.186 G 5.187 G 5.188 G 5.189

M 1.59 UM A X X X X X XM 2.351 PK AM 2.354 PK Z X XM 2.355 BE CM 2.356 BE C X XM 2.357 UM B X X X XM 2.358 UM AM 2.359 BT B X X XM 2.360 BT B XM 2.361 AU CM 2.362 PK AM 2.525 PK A X X X X X X X X XM 2.526 UM A X XM 2.527 BT BM 2.528 PK Z X XM 2.529 PK WM 3.54 UM A X XM 3.92 PK WM 4.80 UM B X X X X X X X X XM 4.274 UM A X X X X X X X X X XM 4.275 BT A X X X X X X X XM 4.447 BT Z X X X XM 4.448 PK Z X X X X X XM 4.449 PK ZM 5.130 UM B X X X X X X XM 6.1 NV A X XM 6.98 NV A

Baustein B 3.303 Speicherl¶sungen / Cloud Storage

Documents

Transcript of Baustein B 3.303 Speicherl¶sungen / Cloud Storage