T. Erb, E. Glutsch, V. Kollmus, H. Gutschmidt, H. Sieber. SyS-C Systemplan

T. Erb, E. Glutsch, V. Kollmus, H. Gutschmidt, H. Sieber SyS-C Systemplan Technischer und Organisatorischer Systementwurf der SyS-C-Plattform zum Anschluss der Chemnitzer Schulen an ein Schulrechenzentrum Vorhabensbezeichnung: Förderkennzeichen: Verbundprojekt: Entwicklung einer Systemlösung für die Schulen der Stadt Chemnitz zur Unterstützung des fachübergreifenden Einsatzes Neuer Medien (SyS-C) 01NM254B Laufzeit des Vorhabens: 01.06.2004 bis 31.05.2007 Zuwendungsempfänger: Autoren: Stadt Chemnitz Dezernat 1 Markt 1 09111 Chemnitz T. Erb, E. Glutsch, V. Kollmus, H. Gutschmidt, H. Sieber Stadt Chemnitz Schulverwaltungsamt Moritzhof 09111 Chemnitz Datum: 21. August 2006 Durch das Bundesministerium für Bildung und Forschung und den Europäischen Sozialfonds gefördertes Projekt

I Systemplan Dokumenthistorie Bearbeiter Datum Änderungen Erb 24.04.2006 Erstellung Erb 25.04.2006 Ergänzungen Glutsch, Gutschmidt, Erb 26.04.2006 Überarbeitung Sieber 30.04.2006 Korrekturen, Fertigstellung der 1. Vorabversion Glutsch, Kollmus, Erb, Gutschmidt 04.05.2006 Fertigstellung Abschnitte 1 bis 4 Glutsch, Sieber 05.05.2006 Ergänzung Arbeitspakete, Korrekturen Kollmus, Gutschmidt 21.08.2006 Überarbeitung für öffentliche Version

II Inhaltsverzeichnis Systemplan... I Inhaltsverzeichnis...II Abbildungsverzeichnis...IV Tabellenverzeichnis...V Legende...VI 1 Allgemeines...1 1.1 Übersicht...1 1.2 Abhängigkeiten...1 1.3 Ausfallszenarien...2 2 Netztopologie...4 2.1 Schulrechenzentrum...4 2.2 Schule...5 2.3 VPN...6 2.3.1 Konzept...6 2.3.2 VPN-Hardware...7 2.3.3 Integration der Schulen...7 2.3.4 Management Zugang...8 2.4 Firewall...8 2.5 Netzpläne...9 3 Komponenten...12 3.1 aktive Netzkomponenten...12 3.2 Minimalsystem...12 3.2.1 Umfang...13 3.2.2 Desaster Recovery...13 3.2.3 Updatemechanismus...13 3.3 Dienste...14 3.3.1 Zuordnung der Dienste...14 3.3.2 Dienste im Detail...14 3.4 Backupsystem...16 3.4.1 Konzept...16 3.4.2 Software...16

III 3.4.3 Restore...17 4 Ausfallszenarien...18 4.1 Ausfall Internetanbindung Rechenzentrum...18 4.1.1 Meldung und Beseitigung...18 4.1.2 DNS...18 4.1.3 E-Mail...18 4.1.4 WWW...18 4.2 Ausfall Internetanbindung Schule...19 4.3 Hardwareausfälle in der Zentrale...19 4.3.1 Monitoring...19 4.3.2 Fehlerbeseitigung...19 4.3.3 Redundanz...19 4.4 Softwareausfall...20 4.4.1 Monitoring...20 4.4.2 Fehlerbeseitigung...20 4.5 Höhere Gewalt...21 4.5.1 Stromausfall...21 4.5.2 Hochwasser...21

IV Abbildungsverzeichnis Abbildung 1: Rechenzentrum...4 Abbildung 2: Schule...5 Abbildung 3: VPN Topologie...6 Abbildung 4: Netzplan...9

V Tabellenverzeichnis Tabelle 1: Vor- und Nachteile der VPN-Topologien...7 Tabelle 2: Übersicht aller Virtuellen LANs...10 Tabelle 3: Zuordnung der Dienste...14

VI Legende Router Switch Server VPN-Terminator Firewall A / S-DSL CMS DMS DMZ DNS DSL FTP HTTP HTTPS ies IP ISDN LAN LDAP NAT NTP SMS Asymmetric / Symmetric-DSL Content Management System Document Management System Demilitarisierte Zone Domain Name Service Digital Subscriber Link File Transfer Protocol Hyper Text Transfer Protocol Hyper Text Transfer Protocol Secure InSecMa easy Schoolserver Internet Protocol Integrated Services Digital Network Local Area Network Lightweight Directory Access Protocol Network Address Translation Network Time Protocol Short Message Service

VII SMTP SNMP SRZ VLAN VPN Simple Mail Transfer Protocol Simple Network Management Protocol Schulrechenzentrum Virtual Local Area Network Virtual Private Network

1 1 Allgemeines 1.1 Übersicht Das Projekt SyS-C hat zur Aufgabe, eine ganzheitliche IT-Systemlösung für Schulen in der Stadt Chemnitz zu schaffen. Das Projekt wird vom Bundesministerium für Bildung und Forschung und dem Europäischen Sozialfonds gefördert. Technisch erfolgen im Rahmen des Projektes der Aufbau eines zentralen Schulintranetzes mit einem Schulrechenzentrum im Mittelpunkt als notwendige infrastrukturelle Basis für die SyS-C-Plattform und die Bereitstellung von zentralen Diensten wie Nutzerverwaltung oder Kinder- und Jugendschutz sowie der Entwurf und die Entwicklung einer SyS-C-Software, die vor allem auch eine einheitliche administrative Oberfläche für die Schulen bietet, welche Voraussetzung für die Nutzung der zentralen Dienste und wesentlich für das zentrale Supportkonzept ist. Das vorliegende Dokument beschreibt den Aufbau der notwendigen Systemplattform, wobei der Schwerpunkt in der Beschreibung des Aufbaus des Schulrechenzentrums liegt. 1.2 Abhängigkeiten Das Projekt SyS-C hat verschiedene technische Abhängigkeiten und wird als Partnerprojekt nicht alleine von der Stadt Chemnitz durchgeführt. Nutzung des Rechenzentrums der Stadt Chemnitz Zentral für die SyS-C-Plattform ist ein Schulrechenzentrum. Dies wird in Chemnitz in den Räumen des Rechenzentrums der Stadt Chemnitz aufgebaut. Das Rechenzentrum bietet eine Klimatisierung und eine zentrale, unterbrechungsfreie Stromversorgung. Alternativ ist für so ein Projekt der Betrieb in einem Rechenzentrum eines Hostingpartners denkbar, was vor allem den Vorteil einer preiswerteren und im Allgemeinen auch redundanten breitbandigen Netzanbindung hätte. Internetanschluss von Schulrechenzentrum und Schulen Der Aufbau des Schulintranetzes erfolgt über VPN-Tunnel durch das Internet. Die Basis bilden der Internetanschluss des Schulrechenzentrums und die Internetzugänge der Schulen. Hier ist mit verschiedenen Anbietern zusammenzuarbeiten. Der Internetzugang des Schulrechenzentrums in Chemnitz wird von der Firma Versatel bereitgestellt. Diese stellt hierfür auch einen kompletten Class-C-IP-Adressraum für die Außenanbindung zur Verfügung. Die Schulen sind mit asymmetrischen und teilweise auch symmetrischen DSL- und ISDN-Zugängen von verschiedenen Anbietern angeschlossen. DNS-Raum c.sn.schule.de Die Stadt Chemnitz nutzt für die Außenpräsenz im Rahmen von SyS-C den DNS-Raum von schule.de. Für Chemnitz lauten die DNS-Namen auf c.sn.schule.de. Der Namensraum schule.de gehört dem ODS e.v. Verantwortlich für die Verwaltung der sächsischen Adressen sn.schule.de ist die TU Chemnitz. Mit beiden Institutionen erfolgte bereits eine

2 Abstimmung der Nutzung der entsprechenden DNS-Namen. Die TU Chemnitz wird dabei die Verantwortlichkeit für c.sn.schule.de an das Schulrechenzentrum delegieren. Softwareentwicklung durch InSecMa Die SyS-C-Software (die Software für die Servicebox mit der Administrationsoberfläche) wird von der Berliner Firma InSecMa entwickelt. Das Systemdesign des SRZ ist mit InSecMa abzustimmen. Das vorliegende Konzept berücksichtigt diese Abstimmung. Änderungen an der SyS-C-Software erfordern gegebenenfalls Anpassungen des Systemdesigns. Beschaffte Hardware Das Systemdesign berücksichtigt Hardware, die für das Projekt im Jahr 2005 beschafft wurde. Damals existierte nur ein vorläufiges Systemdesign, auf dessen Basis die Hardware ausgewählt worden ist. Für das aktuelle Design ist die Verwendung alternativer Hardware denkbar; in manchen Punkten wäre das im Nachhinein auch günstiger gewesen. 1.3 Ausfallszenarien Für den Systementwurf spielt die Berücksichtigung von Ausfallszenarien eine wichtige Rolle. Für SyS-C werden dabei speziell die folgenden möglichen Ausfälle betrachtet: Ausfall der Internetanbindung des Rechenzentrums Der (nichtredundante) Internetzugang des Providers fällt aus. Da sowohl das SyS-C-Netz intern (über VPN) wie auch die Außenanbindung darüber läuft, handelt es sich dabei um einen schwerwiegenden Fehler für SyS-C. Die Wahrscheinlichkeit für einen Ausfall kann im Moment noch nicht geschätzt werden, sie sollte aber eher gering sein. Ausfall der Internetanbindung einer Schule Die Schulen haben Internetzugänge verschiedener Art und von unterschiedlichen Providern. Meist handelt es sich um T-DSL-Anschlüsse. Fällt dieser Anschluss aus, ist davon nur die entsprechende Schule betroffen. Der Ausfall ist minderschwer für SyS-C. Ein Ausfall der Internetanbindung irgendeiner Schule wird im Betrieb von SyS-C mit hoher Wahrscheinlichkeit irgendwann auftreten, da hier ca. 85 Schulen ausfallen können. Der Grund kann in technischem Versagen oder auch in einem menschlichen Fehler liegen. Hardwareausfälle Denkbar sind Ausfälle von Servern, von Netzkomponenten, von Festplatten in Raid-Verbünden usw. Immer sind mehr oder weniger viele Dienste von SyS-C betroffen. Bei der Menge der eingesetzten Hardware ist mit an Sicherheit grenzender Wahrscheinlichkeit von Hardwareausfällen im Rahmen des Betriebs von SyS-C zu rechnen.

3 Softwareausfälle Durch Fehler in der eingesetzten Software, Installations- oder Nutzerfehler oder auch ungenügenden Festplattenplatz kann es zum Ausfall von einzelnen Diensten kommen. Die Erfahrung zeigt, dass bei ähnlich komplexen Systemen Softwarefehler immer wieder vorkommen. Auch im Betrieb von SyS-C wird es Ausfälle geben, die auf Fehler in der Software zurück zuführen sein werden. Höhere Gewalt Dazu zählen Feuer und - speziell auch für das Schulrechenzentrum in Chemnitz interessant - Hochwasser. Ebenso ist hier ein Stromausfall zu betrachten. Im schlimmsten Fall ist durch den Einfluss höherer Gewalt eine totale Zerstörung des Schulrechenzentrums möglich. Die Wahrscheinlichkeit für eine totale Zerstörung des Schulrechenzentrums durch die genannten Fehler ist eher sehr gering. Allerdings ist an der Position des technischen Rathauses schon Hochwasser vorgekommen. Stromausfälle sind immer möglich und nie auszuschließen. Wahrscheinlicher sind dabei kurze Stromausfälle, in seltenen Fällen ist in Chemnitz der Strom aber auch bereits mehrere Stunden in der Vergangenheit ausgefallen. Im Systemdesign werden alle vorgestellten Ausfälle angemessen berücksichtigt. Eine kompakte und zusammenfassende Darstellung zum Umgang mit verschiedenen Ausfällen erfolgt im Abschnitt 4 dieses Dokumentes.

4 2 Netztopologie 2.1 Schulrechenzentrum Die folgende Abbildung zeigt schematisch den Aufbau des Schulrechenzentrums (SRZ). Abbildung 1: Rechenzentrum Der Internetzugang des SRZ wird durch einen Access Router realisiert. Dieser führt gleichzeitig ein rudimentäres Filtering durch, um unerwünschte IP-Pakete bereits an dieser Stelle zu verwerfen. Die zentrale Firewall gewährleistet den Schutz aller dahinter befindlichen Netze. Dazu gehören die DMZ für externe Dienste, das LAN für interne Dienste sowie das Administrations-LAN für den internen Managementzugriff (einschließlich der Integration des Büronetzes am Standort des SRZ). Den Endpunkt für alle VPN-Zugänge bildet ein VPN-Terminator, der aus diesem Grund direkt hinter dem Access Router angeordnet ist.

5 2.2 Schule Die folgende Abbildung zeigt den Anschluss der Schulen ans Internet und die Integration der bestehenden Schulnetze: Abbildung 2: Schule Der Internetzugang jedes Schulstandortes wird über einen Access Router realisiert. Dieser fungiert gleichzeitig als VPN-Gateway zur Integration des Schulnetzes in das VPN sowie als IP-Filter für das lokale Netz. Die Servicebox mit der SyS-C Software stellt die Schnittstelle für das lokale Schulnetz zum Internet dar, wobei diese wiederum die Dienste des SRZ nutzt. Diese Software beinhaltet eine einfach zu bedienende einheitliche Administrationsoberfläche, die den Belangen des schulischen Alltags Rechnung trägt.

6 2.3 VPN 2.3.1 Konzept Die Anbindung der Schulen an die zentrale Plattform erfolgt über eine VPN-Infrastruktur, die alle lokalen Schulnetze zu einem strukturierten privaten Netz zusammenfasst. Wie in Abbildung 3 dargestellt, handelt es sich hierbei um eine Sterntopologie, das heißt, es besteht immer ein VPN- Tunnel zwischen einem Schulstandort und dem SRZ, nicht jedoch zwischen zwei Schulstandorten. Abbildung 3: VPN Topologie Die Entscheidung fiel zugunsten der Sterntopologie, da dynamische IP-Adressen eine Vollvermaschung mit VPN-Tunneln nicht zulassen. Vor- und Nachteile der verschiedenen Topologien sind aus Tabelle 1 ersichtlich.

7 Vorteile Anzahl VPN-Tunnel ist überschaubar Sicherheitsmechanismen des SRZ können nicht umgangen werden Vorteile Ausfall des SRZ hat keinen Einfluss auf Kommunikation zwischen den Schulstandorten Sterntopologie Nachteile Kommunikation zwischen den Schulstandorten wird über das SRZ abgewickelt, Bandbreitenengpass Ausfall des SRZ zieht Isolation der Schulen nach sich Vollvermaschung Nachteile Hohe Anzahl VPN-Tunnel ist kaum beherrschbar dynamische IPs verhindern den Tunnelaufbau zwischen den Schulstandorten Sicherheitsmechanismen des SRZ werden umgangen Tabelle 1: Vor- und Nachteile der VPN-Topologien Da über die VPN-Anbindung schützenswerte Daten (z. B. Remote Management, Nutzerdaten) übertragen werden, kommt als Übertragungsprotokoll IPsec zum Einsatz. Authentifizierungsdaten der VPN-Clients werden auf einem Radiusserver gemanagt. Externe Admin- und Wartungszugänge werden ebenfalls über VPN-Tunnel mit der Zentrale verbunden. Sie unterscheiden sich von den Schulen nur durch die ihnen zugewiesenen erweiterten Zugriffsrechte. 2.3.2 VPN-Hardware Als VPN-Terminator wird ein Universalrouter aus der Cisco Routerserie 3800 eingesetzt. Die Entscheidungskriterien hierfür waren: moderne Hardwarearchitektur hohe Investitionssicherheit durch hohe Leistung und Modularität QoS-Möglichkeit wird durch IOS unterstützt Unterstützung von über 90 zusätzlichen Modulen in Verbindung mit 3 freien Modulslots 2.3.3 Integration der Schulen Jedes Schulnetz stellt ein Ethernetsegment dar, in dem sich der Access Router, die Servicebox und alle Arbeitsplatz-PCs befinden. Für die Dienste http, https, ftp und smtp übernimmt die Servicebox Proxyfunktionalität. Alle anderen freigegebenen Dienste werden direkt in den VPN-Tunnel geroutet. Darüber hinaus besteht am Schulstandort kein direkter Internetzugang. Der Aufbau des VPN-Tunnels erfolgt stets vom Access Router/VPN-Gateway, da als Zugangstechnologie nahezu an allen Standorten

8 Verfahren mit dynamischer IP-Vergabe zum Einsatz kommen. Gleichzeitig übernimmt der Access Router die Firewallfunktion. Die Servicebox nutzt den bestehenden VPN-Tunnel sowohl zur Bereitstellung aller Internetdienste für die Arbeitsplatz-PCs als auch für notwendige Managementfunktionen (Datenabgleich etc.). 2.3.4 Management Zugang Externe Admin- und Wartungszugänge werden ebenfalls über VPN-Tunnel realisiert, da diese ähnlich zu den Schulstandorten eingerichtet sind. Darüber hinaus erfolgt die Vergabe spezieller Zugriffsrechte (z. B. Access Listen) für den Zugang zum internen Admin-Netz auf unterster Ebene. Zusätzlich erfolgt in zweiter Ebene eine Authentifizierung/Authorisierung an der konkreten Komponente. 2.4 Firewall In der Zentrale übernimmt der Access Router ein erstes Filtern unerwünschter IP-Pakete. Die Firewall des SRZ übernimmt folgende spezielle Funktionen: Filterung zwischen DMZ und Internet - in/out je nach Dienst Filterung zwischen Schulstandorten/Servicebox und LAN interne Dienste in (über VPN Terminator) Filterung zwischen den Schulstandorten/Serviceboxen untereinander (über VPN Terminator) Filterung und NAT zwischen LAN interne Dienste und Internet nur out Filterung und NAT zwischen Admin-LAN und Internet out, nur für Update-Dienste Filterung und NAT zwischen Büro und Internet out In den Schulen übernimmt der Cisco-Router das Filtern unerwünschter Pakete aus dem Internet und des VPN-Traffics.

9 2.5 Netzpläne Abbildung 4: Netzplan Das zugewiesene öffentliche Class-C-Netz wird in die drei Subnetze Transfernetz Provider Router / Access Router, Access Netz für VPN-Terminator und Firewall, sowie Subnetz für die DMZ aufgeteilt. Dahinter werden mit privaten IP-Adressbereichen verschiedene Netze strukturiert und über VLAN getrennt.

10 VLAN Zweck Komponenten Administrationsnetz Server der Administrationsnetz der aktiven Netzkomponenten alle Server in der DMZ und im LAN interne Dienste alle Router, alle Switche, VPN-Terminator, Firewall SyS-C Büro Notebooks, PCs des Büros, die nicht im stadtinternen Netz sind LAN interne Dienste DMZ alle Server des LAN interne Dienste der DMZ-Server und der Standby-Server der DMZ Tabelle 2: Übersicht aller Virtuellen LANs Neben der IP-Adresse für die Server werden auch jeweils IP-Adressen für die Dienste vergeben und auf den Servern konfiguriert. Damit können bei Bedarf Dienste einfach auf andere Server verschoben werden. Nachfolgende Übersicht welche Dienste in den Teilnetzen aufgebaut werden. Teilnetz DMZ LAN interne Dienste Administrationsnetz Server der Dienste Nameserver Mailserver + Relay Webserver + CMS Zeitserver Ticketsystem Proxy Mailserver ies mit LDAP Primary Nameserver Zeitserver intern Secondary Nameserver (Schulen und Zentrale) Proxy Jugendschutzfilter Proxy Contentfilter Webserver + CMS Projektmanagement Windows-Update-Server Storage Monitoring Logserver Recovery + Securityupdates

11 ftp für CentOS ftp Netzkomponenten Cyrus Radiusserver Testserver Backup

12 3 Komponenten 3.1 aktive Netzkomponenten Die Übersicht zu den aktiven Netzkomponenten wurde in der öffentlichen Version entfernt. 3.2 Minimalsystem Bei der Installation der Server dient eine Minimalinstallation von CentOS 4.3 als Basissystem, welches auf allen Servern identisch installiert wird. Die im Minimalsystem enthaltenen Pakete sind in einer Kickstart-Datei enthalten, die abgesehen von der Netzwerkkonfiguration, bei allen Servern identisch ist. Mit Kickstart wird eine automatisierte Installation durchgeführt, die Parameter dafür stehen in der kickstart-datei. Die auf den Rechnern zu installierenden Dienste werden im Anschluss an die Minimalinstallation mit Hilfe von cfengine auf die Server installiert und konfiguriert.

13 3.2.1 Umfang Um die Installation möglichst klein zu halten, werden lediglich einige Basisdienste installiert. Grundsätzlich verzichtet wird insbesondere auf die Installation einer grafischen Benutzeroberfläche und Anwendungsprogramme. Folgende Komponenten sind Teil der Minimalinstallation: Deutsche Lokalisierung (Zeitzone, Tastaturlayout), OpenSSH (Server+Client), NTP-Client, SNMP-Dienst. 3.2.2 Desaster Recovery Um einen Server neu aufzusetzen sind drei Arbeitsschritte erforderlich: Installation des Minimalsystems mit kickstart, Erweiterung des Systems und Konfiguration der Dienste mit cfengine, Einspielen der Daten aus dem Storage. 3.2.3 Updatemechanismus Auf einem Server werden alle Security-Updates automatisch von einem Server im Internet geholt. Die benötigten Updates werden manuell eingespielt und dokumentiert.

14 3.3 Dienste 3.3.1 Zuordnung der Dienste Im SRZ stehen 19" Rack Server (Fujitsu-Siemens-Computer Primergy RS200-S2) in verschiedenen Ausbaustufen von CPU und Hauptspeicher zur Verfügung. Diese Übersicht zeigt die Kombination auf Aufteilung der Dienste auf verschiedene Server. Dienste Nameserver Mailserver Relay Zeitserver Proxy Server Typ 2 Webserver + CMS Typ 4 Ticketsystem Typ 4 Mailserver Primary Nameserver Zeitserver intern Typ 3 ies mit LDAP Typ 1 Secondary Nameserver (Schulen und Zentrale) Proxy Jugendschutzfilter Typ 2 Proxy Contentfilter Typ 1 Webserver + CMS Typ 1 Projektmanagement Typ 2 Windows-Update-Server Typ 4 Monitoring Typ 4 Logserver ftp Netzkomponenten Recovery + Securityupdates ftp für CentOS Radiusserver Typ 4 Typ 4 Cyrus Typ 3 Testserver Typ 2 Backup Typ 5 Tabelle 3: Zuordnung der Dienste 3.3.2 Dienste im Detail 3.3.2.1 DNS Der Primary Nameserver für die Domain c.sn.schule.de und alle extern sichtbaren Subdomains (z. B. Webpräsenzen der Schulen) steht in der DMZ für externe Dienste. Der Secondary Nameserver soll bei der TU Chemnitz betrieben werden.

15 Für die interne Domain des Schulrechenzentrums steht ein Primary Nameserver im Bereich der internen Dienste. Dort befindet sich auch der Secondary NS, der gleichzeitig Secondary NS für die Schuldomains ist. 3.3.2.2 NTP ntp1 in der DMZ für externe Dienste synchronisiert sich mit Zeitservern aus dem Internet. ntp2 im LAN für interne Dienste synchronisiert sich mit ntp1. Alle anderen Server (einschließlich der Serviceboxen) holen sich von dort die Zeit. 3.3.2.3 E-Mail Der Mailserver in der externen DMZ ist für alle Schul-Subdomains von c.sn.schule.de zuständig, entscheidet, welche Mails er annimmt und leitet diese Mails weiter an den internen Mailserver. Dieser wird dann auf Viren scannen und die Mails, die angenommen und mit hoher Wahrscheinlichkeit als Spam identifiziert wurden, gekennzeichnet. Die Mails für die Mitarbeiter im SRZ werden lokal abgelegt, alle Mails für die Schulen an die MTA auf den Serviceboxen weitergeleitet. In der Zentrale wird ein Cyrus laufen. Im Falle eines Ausfalls des externen Mailservers soll ein Server der TU Chemnitz die Mails vorhalten. 3.3.2.4 LDAP Um alle für die Authentifizierung relevanten Daten konsistent zu halten, werden sie prinzipiell in den LDAP der Zentrale eingetragen. Anschließend wird der jeweils für die Schule relevante Teil des LDAP-Stammes auf die Servicebox des Schulstandortes repliziert. Damit ist die Aktualisierung der LDAP-Daten auf den Serviceboxen nur über Replikation durch die Zentrale möglich. Das Replizieren in die Schulen macht ein schulinternes Arbeiten ohne VPN-Tunnel möglich. 3.3.2.5 Proxy / Kinder- und Jugendschutz Sämtlicher Webverkehr der Schulen wird über den Proxy der Zentrale geleitet. Damit wird gewährleistet, dass ein Jugendschutzfilter passiert werden muss. Außerdem wird der gesamte WebTraffic auf Viren geprüft. 3.3.2.6 Monitoring Eine Überwachung der Hardwarekomponenten und Systemzustände wird per SNMP erfolgen, Ereignisse werden per Traps gemeldet. Zur Erkennung von Trends und Entwicklungen (Temperaturverläufe, Trafficentwicklung etc.) wird ein Verlaufsmonitoring erfolgen. 3.3.2.7 WWW-Server Alle Schulen haben die Möglichkeit, sowohl eine intern als auch eine extern sichtbare Webpräsenz zu erstellen. Die Inhalte werden über ein Content-Management-System erstellt und verwaltet und auf die entsprechenden Webserver repliziert. 3.3.2.8 Groupware Für das interne Projekt- und Dokumenten-Management wird eine Groupware-Lösung installiert und gepflegt. 3.3.2.9 Ticketmanagement (OTRS) Supportanfragen werden über ein Ticketmanagementsystem abgewickelt.

16 3.3.2.10 Logging Die Speicherung von Logdateien erfolgt auf einem zentralen Server, um das Management sowie die Umsetzung rechtlicher Anforderungen zu vereinfachen. Rechtlich relevante Logs werden in das Backup-System aufgenommen. 3.3.2.11 Windows-Updateserver Ein Server mit Microsoft Windows Server Update Services (WSUS) wird für die Updates von Windows-Clients und Windows-Applikationsservern eingesetzt. 3.3.2.12 Recovery-Server Dieser Server ist für die ersten beiden Stufen des Desaster-Recoverys (siehe 3.2.2), die Erstinstallation der Server und die Aktualisierung der Konfigurationen auf den Servern zuständig. 3.4 Backupsystem 3.4.1 Konzept Als Backup-System stehen ein Storage und eine Tape-Library zur Verfügung. Als Software kommt ArcServ, welches auf einem Windows 2003-Server installiert ist, zum Einsatz. Prinzipiell muss auf jedem Clientsystem, das in das Backup aufgenommen werden soll, ein Backupagent installiert werden (für Linux und Windows verfügbar). Dann ist der jeweilige Client im Backup sichtbar und Verzeichnisse/Dateien können gesichert werden. Ein Bootserver mit allen kickstart-dateien sowie die Konfiguration in cfengine wird ebenfalls aufgesetzt und in das Backup aufgenommen. Dann müssen die einzelnen Konfigurationen der Server nicht extra gesichert werden und die SRZ-Server können auch unproblematisch wieder neu aufgesetzt werden. Neben der eigentlichen Backupproblematik ist davon auszugehen, dass bei bestimmten, personenbezogenen Daten (z. B. Zugriffslogs) gewisse rechtliche Vorgaben wie beispielsweise eine Mindest- oder eine Höchstspeicherdauer eingehalten werden müssen. Relevante Daten für das Backup: alle Datenbanken (LDAP, Ticketsystem, CMS, DMS/Projekt): eine Auswahl von Logdateien, DNS-Zonefiles, ies-server, Webseiten der Internetpräsentationen, Serviceboxen (Auswahl von Verzeichnissen/Dateien). Umgang mit den Tapes 6 Tagesbänder (Mo bis Sa), 4 Wochenbänder (So 1. bis 4. Woche), 6 Monatsbänder (1+7 bis 6+12). 3.4.2 Software CA ArcServ

17 3.4.3 Restore Für das Restore stehen mehrere Wege offen. Entweder man spielt direkt das Backup wieder ein oder man nimmt den Snapshot und stellt die Daten auf dem Storage wieder her und kopiert dann auf den jeweiligen Server.

18 4 Ausfallszenarien 4.1 Ausfall Internetanbindung Rechenzentrum Das Schulrechenzentrum wird ohne Redundanz zum Provider angebunden. Bei einem Ausfall des Internetanschlusses sind sowohl die Verbindung SyS-C Internet wie auch das SyS-C-Netz betroffen. Aufgrund der Struktur des Systems können in so einem Fall die Schulen lokal weiterarbeiten, da die Nutzerdaten und Homeverzeichnisse auf den Serviceboxen der Schulen liegen. Systemerweiterungen sind immer so auszulegen, dass dies auch in Zukunft gewährleistet ist. Auf der anderen Seite sind bei einem Netzausfall keine Administrationstätigkeiten mehr möglich. Insbesondere können keine Nutzer angelegt oder verändert werden. Weiterhin ist in diesem Fall für alle Chemnitzer Schulen der Internetzugang nicht mehr möglich. Es handelt sich folglich um eine schwerwiegende Störung, die umgehend beseitigt werden muss. Dies ist jedoch nur in Zusammenarbeit mit dem Provider möglich. 4.1.1 Meldung und Beseitigung Für eine umgehende Beseitigung der Störung sind folgende Maßnahmen zu treffen: Es ist eine Lösung einzurichten, die einen verantwortlichen Administrator 7x24 über die eingetretene Störung informiert. Empfohlen wird der Einsatz eines SMS-Moduls, über das auch bei unterbrochener Netzanbindung Nachrichten versand werden können. Für Netzstörungen ist ein Ablauf für die Meldung der Störung an den Provider festzulegen und die Fristen für die Problemlösung sind vertraglich zu vereinbaren. 4.1.2 DNS Auf den Serviceboxen läuft ein eigener DNS, so dass dieser Dienst schulintern weiterhin verfügbar ist. Damit auch die Domain c.sn.schule.de weiterhin aufgelöst werden kann (um z.b. E-Mail zu versenden), ist ein sekundärer DNS einzurichten. In Verbindung mit einem sekundären Mailserver könnte dies ggf. die TU Chemnitz übernehmen, entsprechende Gespräche sind zu führen. 4.1.3 E-Mail Im Fall einer Störung muss E-Mail weiterhin schulintern verschickt werden können. Ebenso muss der Versand von E-Mail zu beliebigen Adressen in SyS-C und außerhalb von SyS-C in der Schule möglich sein, die E-Mails sind vom MTA auf der Servicebox zwischenzuspeichern. Die Erreichbarkeit des SyS-C-Netzes für E-Mail von außerhalb ist dadurch zu gewährleisten, dass ein sekundärer Mailserver (entsprechender MX-Eintrag im DNS) eingerichtet wird. Hier könnte die TU Chemnitz gebeten werden, einen solchen einzurichten. 4.1.4 WWW Der Zugriff auf das WWW ist für die Schulen nicht mehr möglich, wenn das SRZ nicht mehr erreichbar ist. Im SRZ läuft der Jugendschutzfilter, aus rechtlichen Gründen sollte auch kein Internetzugang für die Schulen ohne Jugendschutzfilter möglich sein. Ein alternativer Internetzugang ist deshalb nicht vorzusehen. Schwerpunkt beim Ausfall der Internetanbindung des SRZ muss die Beseitigung der Störung sein.

19 4.2 Ausfall Internetanbindung Schule Der Ausfall der Internetanbindung der Schule hat nur Auswirkungen auf den Betrieb des Schulintranets der betroffenen Schule. Die Störung ist deshalb minderschwer. Die Software der Serviceboxen ist so auszulegen, dass auch ohne Netzanbindung der Schule eine lokale Arbeit noch möglich ist. Siehe dazu auch die Ausführungen im Abschnitt 4.1. Um eine zügige Beseitigung der Störung herbeizuführen, ist diese geeignet anzuzeigen: Auf der Servicebox muss im Statusmonitor ein Fehler beim Netzzugang angezeigt werden. Aus der Fehlermeldung sollte hervorgehen, ob die Störung im Internetanschluss der Schule oder aus einer Störung der Erreichbarkeit des Schulrechenzentrums besteht. Im Schulrechenzentrum muss die Störung im Managementsystem angezeigt werden. Es sind Abläufe schriftlich festzulegen, die beschreiben, welcher Dienstleister wie im Falle einer Störung zu informieren ist. 4.3 Hardwareausfälle in der Zentrale Ein Hardwareausfall liegt vor, wenn eine der aktiven Netzkomponenten oder ein Server ausfällt oder wenn ein Teilausfall (z. B. Festplatte eines Raid-Verbundes) vorliegt. 4.3.1 Monitoring Der Ausfall von allen für den Betrieb notwendigen System ist zu monitoren. Je nach Schwere des Ausfalls muss die Benachrichtigung gesteuert werden können. Zur Benachrichtung werden E-Mail und SMS-Meldungen benutzt. Der Systemstatus wird in Nagios überwacht. Die Startseite im Nagios gibt einen guten Überblick über den aktuellen Systemzustand und ist im Allgemeinen die Startseite für die Administratoren. 4.3.2 Fehlerbeseitigung Die Fehlerbeseitigung besteht aus der Reparatur der betroffenen Hardware und der Wiederinbetriebnahme des Systems, vor allem im Installieren der Software und Einspielen evtl. Systembackups. 4.3.2.1 Reparatur Für jedes Hardwaresystem werden schriftliche Reparaturanleitungen erstellt, die Kontaktpersonen, Vertragsbedingungen und weitere Informationen zur Reparatur enthalten. Es sind Zeiten festzulegen und vertraglich zu vereinbaren, innerhalb derer Reparaturen durchzuführen sind. 4.3.2.2 Wiederinbetriebnahme Für jedes System ist eine schriftliche Anleitung zur Wiederinbetriebnahme zu erstellen, die vor allem auch die Anleitung zur Wiederinstallation der Software und zum Einspielen von evtl. Backups enthält. 4.3.3 Redundanz Entsprechend der Ausführungen weiter oben in diesem Dokument sind verschiedene Systeme redundant ausgelegt. Die TU Chemnitz betreibt einen sekundären DNS-Server, so dass die externen DNS-Einträge der Stadt Chemnitz (*.c.sn.schule.de) auch bei einem Netzausfall des SRZ aufgelöst werden können (siehe Abschnitt 3.3.2.1).

20 Die Erreichbarkeit für E-Mail von außerhalb des SyS-C-Netzes wird redundant ausgelegt, indem an der TU Chemnitz ein sekundärer Mailserver betrieben wird (siehe Abschnitt 3.3.2.3). Die Außenanbindung wird durch einen Server in der DMZ realisiert. Ihm wird eine identische Maschine zur Seite gestellt, die im Falle eines Hardwaredefektes den Betrieb sofort übernehmen kann. Dazu wird dieser Server identisch konfiguriert, nur wird der Switchport in die DMZ deaktiviert. Der Zugriff auf die Maschine erfolgt über das Admin-VLAN. Der DNS-Dienst wird innerhalb des SyS-C-Netzes redundant über einen sekundären Nameserver ausgelegt. In der Serverfarm werden Maschinen mit Minimalsystem vorgehalten, die aktuell nicht benötigt werden und im Falle eines Ausfalls schnell die Funktion des ausgefallenen Systems übernehmen können. Darüber hinaus erfolgt kein redundanter Aufbau des Systems. Wesentliche Komponenten für einen stabilen Betrieb sind somit ein umfassendes Monitoring mit schneller Information über Systemfehler, umfassende und aktuelle Backups aller Konfigurations- und Systemdaten, Ersatztechnik, die sofort einsatzbereit ist und Strategien zum schnellen Wiederaufsetzen eines Servers. Dadurch, und unter Berücksichtigung der Qualität der eingesetzten Technik, sollte eine hohe Verfügbarkeit des SyS-C-Netzes gewährleistet werden können. 4.4 Softwareausfall Neben Ausfällen von Hardware ist es auch möglich, dass einzelne Dienste auf Grund von Fehlern in der Software, Fehlkonfigurationen oder Fehlbedienungen ausfallen. Je nach Dienst sind solche Ausfälle von unterschiedlicher Schwere. 4.4.1 Monitoring Im Rahmen des Monitoring sind die folgenden Punkte zu überwachen und im Falle von Warnungen oder Fehlern entsprechende Meldungen zu generieren: Erreichbarkeit von Diensten, Füllgrad von Filesystemen, evtl. dienstespezifische Monitorfunktionen. Es sind mind. alle für SyS-C notwendigen Dienste entsprechend der gegebenen Möglichkeiten zu monitoren. Für alle beobachteten Werte ist festzulegen, wie im Fall vom Erreichen von Warn- oder Fehlerstufen zu verfahren ist. Im Schulrechenzentrum sind alle Dienste zu monitoren. In den Schulen sind nur Dienste zu monitoren, die auf der Servicebox laufen. 4.4.2 Fehlerbeseitigung Für die effektive Fehlerbeseitigung ist eine Wissensdatenbank anzulegen, in der bekannte Fehler und Hinweise zur Fehlerbehebung gespeichert werden.