Standard-Dienstleistungsvereinbarung (Servicebased SLA) für "LDAPS" - Informatikdienste Direktion - ETH Zürich
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Informatikdienste
Direktion
ETH Zürich
Stampfenbachstrasse 69
8092 Zürich
www.id.ethz.ch
Informatikdienste
Standard-Dienstleistungsvereinbarung (Service-
based SLA) für «LDAPS»Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Inhaltsverzeichnis
1. Servicebeschreibung ............................................................................................................... 4
2. Qualitätsmerkmale ................................................................................................................... 5
3. Überwachung und Performance-Analyse ................................................................................ 8
4. Konditionen und Optionen ..................................................................................................... 10
5. Administratives ...................................................................................................................... 10
6. Allgemeine Richtlinien ........................................................................................................... 12
Tabelle 1: Versionskontrolle .......................................................................................................... 3
Seite 2 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Versionskontrolle
Version Historie / Status Datum Autor/in
0.1 Draft 2.10.2017 Dr. Vladislav Nespor
0.2 Korrekturen und Ergänzungen 9.10.2017 Dr. Matteo Corti
0.3 Korrekturen und Ergänzungen 23.1.2019 Dr. Matteo Corti
0.4 Korrekturen und Ergänzungen 28.1.2019 Dr. Cristian Tuduce
1.0 Finalisierung 8.4.2019 Dr. Matteo Corti
1.1 Korrektur SLC 14.9.2021 Dr. Matteo Corti
Tabelle 1: Versionskontrolle
Seite 3 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
1. Servicebeschreibung
Der LDAPS-Service ist ein ETH-weiter Authentifizierungs-, Autorisierungs- und Informationsdienst
auf Basis der OpenLDAP-Software. Der Service dient als zentrale Informationsquelle für
Applikationen und Systeme, und ermöglicht den Austausch von Informationen über User,
Gruppen, Systeme und Dienste.
1.1. Nutzen für die Kunden
Die Kunden des LDAPS-Services sind typischerweise Dienstleistungsanbieter, die ihre Dienste
durch eine User-Authentifizierung und Autorisierung schützen möchten, sowie System-
administratoren, die das LDAPS-Directory als Informationsquelle für ihre Systeme nutzen. Der
LDAPS-Service ist nicht für direkte User-Zugriffe gedacht.
In der Vergangenheit haben einige Institute und Departemente der ETH eigene LDAP-Directories
betrieben. Das hat zwei wesentliche Nachteile: (i) es ist mit finanziellem Aufwand verbunden und
bindet wertvolle Ressourcen, und (ii) es könnte die Nutzung von anderen zentralen Diensten der
ETH (z.B. ID Speicher-Dienste) erschweren oder ganz verhindern, falls die Departements-Daten
inkonsistent mit den zentralen User- und Group-Daten im zentralen LDAPS-Subtree sind.
Der LDAPS-Service bietet den Instituten und Departementen die Möglichkeit, die hochverfügbare
und redundante Infrastruktur des LDAPS-Services zu nutzen und direkt auf die zentralen Daten
zuzugreifen.
Typische Einsatzfälle des LDAPS-Service sind:
Authentifizierung und Autorisierung: Die LDAPS-Directory speichert einheitliche User- und
Group-Daten, welche die Kunden für einfache bis sehr komplexe User-Authentifizierungen und
Autorisierungen benutzen können. Diese Daten werden auch von anderen zentralen ID-Diensten
benutzt.
Informationsquelle: Im LDAPS sind zusätzliche User-Attribute (z.B. E-Mail-Adressen, Telefon-
Nummern, Institutszugehörigkeit usw.) gespeichert, welche die Applikation auch direkt nutzen
können.
Directory-Hosting: Die ETH Departemente haben die Möglichkeit, im LDAP-Directory eigene
Daten (z.B. NIS Maps) in einem separaten Subtree zu verwalten. Der Departements-Subtree kann
auch bei der User- und Group-Migration des eigenen LDAP-Directory in den zentralen LDAPS-
Service dienen.
Departments-eigene User-Attribute: Die ETH-Departemente haben eine limitierte Möglichkeit,
eigene User-Attribute (z.B. ein anderes User-Home-Directory) zu benutzen. Die Attribute sind im
ETH-lokalen Schema definiert, und Attribut-Werte sind direkt im zentralen Subtree gespeichert.
Man kann sie dann entweder auf der Applikations-Seite, oder auf der Server-Seite (in Virtual
Views) den gewünschten Attributen zuordnen (Mapping). In der ETH-Installation der
OpenLDAPS-Software besteht auch die Möglichkeit, alternative User-Kennwörter zu definieren.
Auf der Server-Seite (in einer Virtual View), kann man dann die Kennwort-Werte dem Attribut
Seite 4 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
userPassword zuordnen. Damit können User potenziell mehrere Kennwörter für verschiedene
Applikationen oder Dienste benutzen.
2. Qualitätsmerkmale
2.1. Architektur
Die Server (Master- und Replica-Server) des LDAPS-Services sind auf zwei Datenzentren
(Zentrum und Hönggerberg) verteilt.
Der LDAPS-Service besteht aus zwei Read-Write Master-Servern (Primär- und Failover-Server),
und aus mehreren Read Only Replica-Servern. Die zentralen User- und Group-Daten sind in
einem zentralen Subtree gespeichert und mit der zentralen IAM-Infrastruktur der ETH
synchronisiert.
Die beiden Master-Server sind gleich konfiguriert und ständig synchronisiert (eine Multi-Master-
Lösung). Der DNS-Aliasname ldaps00.ethz.ch bestimmt, welcher Master-Server produktiv
(primär) ist, und die Write-Operationen bearbeitet. Der gleiche produktive Master-Server ist auch
die Quelle für die Master-Replica-Synchronisierung. Sollte der produktive Master-Server
ausfallen, kann der zweite Master-Server (Hot Standby) in dem anderen Datenzenter die Last
übernehmen (eine Aliasnamensverschiebung von ldaps00.ethz.ch im DNS ist dazu notwendig).
Die Replica-Server haben die gleiche Software- und Hardware-Konfiguration. Sie sind
gleichwertig und können alle jederzeit Read-Only-Operationen (Abfragen) beantworten. Die
Kunden erreichen die sechs Replica-Server über den DNS-Aliasnamen ldaps-rz-1.ethz.ch bis
ldaps-rz-3.ethz.ch, und ldaps-hit-1.ethz.ch bis ldaps-hit-3.ethz.ch. Der siebte Replica-Server ist
für den polybox-Dienst den Informatikdiensten reserviert.
Welcher Replica-Server primär kontaktiert wird und welche weiteren Replica-Server als Failover
dienen, bestimmt die Konfiguration auf dem LDAP-Client. Es liegt in der Verantwortung der
Kunden, die Replica-Server von beiden Datenzentren in die Konfiguration aufzunehmen. Die
Replica-Server haben genug Performance, um die ganze Last zu übernehmen, sollte ein
Datenzenter ausfallen.
2.2. Verfügbarkeit
Dieser IT-Service ist als «kritischer Service» (Blau) eingestuft. Das bedeutet:
- Überwachung: 7*24
- Servicezeit: 7*16h (06:00-22:00)
Während dieser Zeit wird alarmiert und die Alarme aktiv bearbeitet. Die Verfügbarkeit
ausserhalb der Servicezeit ist nicht garantiert und ein allfälliger Unterbruch fliesst nicht in
die Verfügbarkeitsmessung ein (keine Auswirkungen auf die Ausfallzeit.
- Garantierte Verfügbarkeit pro Jahr: 99.95 %.
Die Verfügbarkeit wird gemessen innerhalb der Servicezeit und ausserhalb von
vereinbarten Wartungsfenstern und ist gemittelt über ein Kalenderjahr. Als Ausfallzeit
wird die Zeit gewertet, wo der Service aus Sicht des Kunden (ausgenommen
Seite 5 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
anderslautende Regelungen unter den Mess- und Bewertungskriterien zu den
Wartungsfenstern) nicht verfügbar ist.
- Wartungsfenster
Unterbrüche während der Servicezeit nur nach n (n=2 bis 6) Wochen Vorankündigung
möglich.
Unterbrüche ausserhalb der Servicezeit nach 1 Woche Vorankündigung, möglich.
- Erste, qualifizierte Information an Kunden nach Auslösung Alarm: £1h innerhalb
Servicezeit
Erste Information an den Kunden nach einer ersten Analyse durch einen Mitarbeitenden
der ID.
- Maximaler Verfügbarkeitsunterbruch (Recovery Time Objective RTO): 4h
Maximaler Zeitraum bis zur Wiederherstellung des Services nach einem Unterbruch.
Gemessen innerhalb der Servicezeit.
- Maximaler Datenverlust (Recovery Point Objective RPO): 24h
Maximal anzunehmender Verlust von durchgeführten Transaktionen nach einem Ausfall.
Wiederherstellungszeiten nach einem Datenverlust können nicht garantiert werden.
Schematische Darstellung der Service-Verfügbarkeit
Tageszeit (Uhrzeit)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Überwachung Überwachung
Alarmierung Servicezeit 7 * 6:00 - 22:00 Uhr
Service Desk Officezeit Mo - Do
erreichbar
Officezeit Fr
Wartungsfenster Wartungsfenster nach 1 Woche
Wartungsfenster nach 2 - 6 Wochen vorheriger Ankündigung 1 Woche
Ankündigung notwendig vorheriger Ankündigung
Reaktion bei best effort
Es wi rd a l a rmi ert und di e Al a rme werden a ktiv bea rbei tet.
Ers te Informa tionen a n den KundenStandard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Proxy-User-Administratoren. In einem zweiten Schritt erhalten die eventuell betroffenen
Benutzenden ebenfalls eine Information.
Bei einer ungeplanten Downtime publizieren wir alle verfügbaren Informationen zu dem
Unterbruch auf der Web-Seite der Informatikdienste1. Bis spätestens 24 Stunden nach
erfolgreichem Abschluss eines derartigen Ereignisses, werden die betroffenen Benutzenden über
den Vorfall per E-Mail informiert.
Wartungsfenster Zeit Ausfallzeit Info Admins Info betroffene User
Generell 06:00 – 07:30 Uhr < 1 Min. Nein Nein
täglich
Grössere geplante Zu Randzeiten Gemäss 6 Wochen im Voraus 1 Woche im Voraus via E-
Wartungsarbeiten gemäss Ankündigung via E-Mail Mail
Ankündigung
(Wochenende)
Ungeplante Downtime n.a. n.a. 1 h nach Ausfall via 1 h nach Ausfall via Web /
Web / 24 h nach 24 h nach Ereignis via Mail
Ereignis via E-Mail / / gemäss «Blockzeit» an
gemäss «Blockzeit» an Arbeitstagen
Arbeitstagen
Tabelle 2: Wartungsfenster – geplant/ungeplant
2.4. Daten- und Betriebssicherheit
Der LDAPS-Service ist ein interner ETH Service. Die LDAP- und LDAPS-Ports auf den Master-
und Replica-Server sind nur vom ETH Netzwerk erreichbar.
Die Daten im LDAP-Directory sind nicht allgemein lesbar. Ein anonymer User kann sich nur
authentifizieren. Ein authentifizierter User kann nur seine eigenen Daten (Attribute) lesen aber
nicht modifizieren. Modifikationen sind nur zentral über das IAM-Tool möglich.
Um das LDAP-Directory durchsuchen zu können, braucht es einen speziellen Proxy-User (Bind-
User). Der Proxy-User ist auf einem Subtree in der LDAP-Directory definiert. Er kann alle Daten
im gleichen Subtree lesen, ausser das Attribut userPassword.
Alle Administratoren die ihre Dienste mit dem LDAPS-Service verbinden möchten, brauchen einen
Proxy-User. Mit diesem ist es auch möglich im Fall einer Störung, den störungsverursachenden
Dienst zu identifizieren, und dessen Administratoren rasch zu kontaktieren.
Modifikation der Daten im LDAP-Directory ist nur mit einem Master-User möglich. Ähnlich wie bei
einem Proxy-User, ist der Master-User auf einem Subtree definiert. Er kann alle Daten im Subtree
modifizieren. Zum Beispiel, die Administratoren von einem Departement-Subtree bekommen
einen Master-User, um ihre Daten verwalten zu können.
Alle Verbindungen von einem LDAP-Client zu den Servern des LDAPS-Service, und zwischen
den Master- und Replica-Servern sind verschlüsselt (TLS – Transport Layer Security). Die
1
https://www.ethz.ch/services/de/it-services/service-desk/sysstat.html
Seite 7 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Verschlüsselung der Verbindung zwischen dem User und dem LDAP-Client liegt in der
Verantwortung des Administrators der Applikation oder des Dienstes.
Die Software und das Betriebssystem der Server (Red Hat Linux) werden auf dem neusten Stand
gehalten. Die Patches werden unverzüglich auf einem Test-System aufgespielt, und die Prozesse
werden getestet. Erst nach erfolgreichen Tests werden zuerst die Replica-Server schrittweise
aktualisiert. Vor dem Update des Master-Servers wird der DNS-Aliasname ldaps00.ethz.ch auf
den zweiten Master-Server (Failover-Server) umgeschaltet.
2.5. Performance
Zurzeit bedient der LDAPS-Service ungefähr 5'200 Client-Rechner. Die durchschnittliche
Nutzungsintensität des Service (alle sieben Replica-Server zusammen) ist ungefähr 1’200
Verbindungen und 45’000 Abfragen pro Minute. Tägliche Maxima können üblicherweise bis zu
3’300 Verbindungen und 200’000 Abfragen pro Minute erreichen und in sehr seltenen Situationen
kurzfristig bis zu 600'000 Abfragen pro Minute. Die Grösse der Log-Daten liegt momentan bei
40GB pro Tag.
Die maximal mögliche Anzahl von Abfragen pro Minute ist stark von der Abfrage abhängig (z.B.
von der Anzahl der Einträge und den Attributen in der Antwort, Abfrage-Filter, Cashing usw.).
Messungen auf einem Test-Server, der identisch mit den produktiven Replica-Servern ist, haben
gezeigt, dass theoretisch über 30'000 Verbindungen und über 300'000 Abfragen pro Minute auf
einem einzelnen Replica-Server möglich sind. Der limitierende Faktor ist hier eher die Grösse der
erzeugten Log-Daten.
2.6. Backup
Alle Replica-Server sind dauerhaft und umgehend mit dem Master-Server synchronisiert. Es ist
möglich jeder Zeit die Back-End-Datenbank (MBD) zwischen den Server zu kopieren, und im Fall
einer Korruption der Back-End-Datenbank auf einem Server, die Daten wiederherzustellen.
Jede Nacht wird auf jedem Server ein Directory-Dump erstellt. Der Directory-Dump ist im ldif-
Format (Text-Format). Er kann zu Wiederherstellung der Daten (auch teilweise) dienen. Die
Directory-Dumps werden 2 Wochen aufbewahrt.
3. Überwachung und Performance-Analyse
Um die Sicherheit des Betriebs und der Daten zu gewährleisten, wird die LDAPS Infrastruktur und
der Service rund um die Uhr (7*24) lokal- (auf dem gleichen Server) und fern-überwacht (von
anderen Servern über das Netz).
3.1. Fernüberwachung
Durch die Informatikdienste (eRanger): Aus 5 verschiedenen externen Netzwerk-Zonen wird
alle 3 Minuten der LDAPS-Service mit einer User-Authentifizierung überprüft. Sollte die User-
Authentifizierung aus mindestens 3 Netzwerk-Zonen scheitern, wird ein ID-Alarm ausgelöst.
Ausfälle werden monatlich statistisch ausgewertet. Die garantierte Verfügbarkeit pro Jahr (aus
Seite 8 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Sicht des Kunden) ist 99.95%.
Durch die Basisdienste (Nagios): Alle Replica-Server werden durch den Nagios-Server der
Gruppe Hosting überwacht.
Durch den LDAPS-Service: Alle einzelnen Replica-Server werden von beiden Master-Server mit
einem Script jede Minute kontrolliert. Dabei wird das Resultat der User-Authentifizierung, und der
Synchronisation-Status über das Attribut contextCSN (CSN - Change Sequence Number)
überprüft. Sollte ein Server 3 Mal hintereinander ein Problem melden, wird ein Alarm ausgelöst.
3.2. Verfügbarkeitsberichte
Die einzelnen Komponenten des Systems werden kontinuierlich auf deren Verfügbarkeit
überwacht. Die Unterschreitung von zuvor gesetzten Grenzwerten führt dabei automatisch zu
Alarmen, welche per E-Mail und/oder Statusanzeige auf einer Überwachungs-Webseite den
zuständigen Personen übermittelt werden. Die daraus entstehenden Folgeaktivitäten werden
durch die Informatikdienste der ETH Zürich ausgelöst und koordiniert ohne aktive Einflussnahme
des Kunden.
3.3. Lokale Überwachung
Durch den systemd-Service: Der OpenLDAP-Prozess (slapd-Daemon) wird über den systemd-
Service auf dem Server gestartet und überwacht. Sollte der slapd-Daemon unerwartet aussteigen,
wird er gleich wieder neu gestartet.
Durch ein Skript: Auf jedem Replica-Server läuft ein Script, das jede Minute kontrolliert, ob das
lokale LDAP-Directory antwortet, und ob es mit dem produktiven Master synchron ist (über das
Attribut contextCSN). Sollte das Script 3 Mal hintereinander ein Problem melden, wird ein Alarm
ausgelöst.
Durch den Daten-Dump: Jede Nacht wird auf allen Master- und Replica-Servern lokal ein Dump
der Directory-Daten durchgeführt. Die Dumps auf den Replica-Servern werden mit dem Dump auf
dem produktiven Master-Server verglichen (genaue Inhalte). Bei Differenzen wird ein Alarm
ausgelöst.
Durch das File Integrity Monitoring: Jede Nacht läuft auf jedem Server ein Intruder Detection-
System, das alle Änderungen im System und Konfigurationen meldet.
3.4. Performance-Analyse
Durch den info-Service: Die Log-Daten auf den Master- und Replica-Servern werden jede
Minute auf einem zentralen Server gesammelt, ausgewertet und in eine PostgreSQL-Datenbank
eingefügt. Die Tabellen sind entweder direkt oder über ein Web-Interface (https://ldaps-
info.ethz.ch/) zugänglich. Die Daten in den Tabellen ermöglichen z.B. eine schnelle Fehlersuche,
einen Vergleich der Server, eine Performance-, oder Client-Analyse, usw.
Seite 9 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
Durch den collectd-Service: Der collectd-Service2 sammelt direkt auf einem Server Daten über
das System und die Applikationen und speichert sie in RRDs (Round Robin Databases). Für den
LDAPS-Service werden verschiedene statistische Werte (z.B. die Anzahl von Verbindungen,
Such-Abfragen, Modifikationen usw.) gespeichert und Mittelwerte bis 5 Jahre aufbewahrt. Diese
Informationen können über ein Web-Interface auf jedem Server (z.B. https://ldaps-
info.ethz.ch/collectd/) graphisch gargestellt und beurteilt werden (z.B. Tendenzen).
4. Konditionen und Optionen
4.1. Preismodell
Dieser IT-Service wird allen Personen mit einer Beziehung (Mitarbeitende, Studierende und
Dozierende) zur ETH Zürich kostenlos zur Verfügung gestellt.
4.2. Kündigung von Mitgliedern der ETH
Die LDAPS-Daten sind von dem zentralen IAM-System aktualisiert. Beim Verlassen der ETH tritt
folgender Prozess in Kraft:
Austritt aus der ETH Eine Infomail informiert über den bevorstehenden Prozess zum Ende des IAM-
Services.
Das Login bleibt während fünf Monaten noch voll funktionsfähig.
Fünf Monate nach Austritt aus der ETH Das Konto wird gesperrt.
Sechs Monate nach Austritt aus der ETH Das Konto wird gelöscht.
Tabelle 3: Austritt aus der ETH
Die Frist von insgesamt sechs Monaten soll den Benutzenden Gelegenheit geben, ihre Daten zu
sichern und auf ein neues System zu übertragen.
5. Administratives
5.1. Service-Aktivierung
Administratoren, die den LDAPS-Service für ihre Applikationen und Systeme benutzen möchten,
brauchen einen speziellen Proxy-User (Bind-User), der die LDAP-Directory durchsuchen darf. Der
Proxy-User ist als LDAPS-Service mit einem technischen User verbunden. Technische User
werden von der ISG (IT Support Gruppe) des Departments im IAM Web Center
(https://password.ethz.ch/) verwaltet. Der LDAPS-Service wird von den Informatikdiensten
aktiviert.
Um den LDAPS-Service aktivieren zu können, sind folgende Informationen erforderlich:
• Der Name des technischen Users.
• Kurze Beschreibung der Applikation oder des Dienstes (ein Satz auf English).
2
Siehe: https://en.wikipedia.org/wiki/Collectd
Seite 10 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
• E-Mail-Adressen der Administratoren und ihrer Stellvertreter.
• Die URL-Adresse des Dienstes, falls vorhanden.
5.2. Subtrees
Den ETH-Departementen kann bei Bedarf ein separater LDAP-Subtree zur Verfügung gestellt
werden.
5.3. Support und Supportzeiten
Sämtliche Supportanfragen, Störungsmeldungen, Incidents und Bestellungen laufen über
unseren zentralen ID Service Desk. Anfragen werden entgegengenommen und sofort an die
richtigen Stellen weitergeleitet oder allenfalls eskaliert. Der gesamte Kommunikationsverkehr wird
überwacht und auf Einhalten unserer internen Qualitätsvorgaben hin geprüft.
Support Stelle ID Service Desk
Support E-Mailadresse servicedesk@id.ethz.ch
Support Telefonnummer +41 44 632 7777
Support Zeiten Mo – Do: 07:30 – 17:30 Uhr
Fr: 06:30 – 16:30 Uhr
Antwortzeit3 für die erste, qualifizierte Antwort 4h
auf Meldung von Incidents während Bürozeiten Es wird keine maximale «Time to Repair» zugesichert.
Tabelle 4: Support und Supportzeiten
Eine allenfalls notwendige Wiederherstellung («Restore») erfolgt durch die Informatikdienste und
wird ebenfalls über den ID Service Desk bestellt. Müssen Daten mehrmals wegen
Fehlmanipulationen wiederhergestellt werden, kann der Aufwand speziell verrechnet werden.
5.4. Eskalation
Störungsmeldungen und Probleme, welche vom ID Service Desk (1st Level Support) nicht gelöst
werden können, werden an die technischen Betreiber des IT-Service (2nd Level Support)
eskaliert. Falls notwendig wird bei Problemfällen auch der Support vom Hersteller (3rd Level
Support) in Anspruch genommen.
5.5. Pflichten Betreiber
Der Leistungserbringer ist verantwortlich für den reibungslosen Betrieb, den Unterhalt und eine
stetige Weiterentwicklung dieses IT-Services. Dies beinhaltet das Management der Daten, die
Architektur der Infrastruktur, die Unterstützung und Erweiterung der bestehenden
Softwarefunktionalität sowie die Security.
Bei Nichteinhaltung der in diesem SLA zusammenfassend beschriebenen Messwerte über den
Zeitraum eines Kalenderjahres betrachtet, wird die ETH rechtzeitig geeignete Massnahmen
3
Unter «Antwortzeit» wird die Zeit vom Eingang der Meldung bis zum Beginn der Diagnose verstanden.
Seite 11 / 12Standard Dienstleistungsvereinbarung (Service-based SLA) für
«LDAPS»
einleiten, um die festgestellte Abweichung innerhalb der nächsten Messperiode (ein Kalenderjahr)
zu korrigieren.
5.6. Pflichten Kunde
5.6.1. Datenhoheit
Die Daten gehören prinzipiell dem Kunden, und der Kunde hat somit die Verantwortung für deren
Benutzung. Er ist demensprechend verpflichtet, alle lokalen und nationalen Gesetzgebungen,
sowie die internen ETH-Richtlinien im Umgang mit Telematik-Ressourcen (6.3 BOT
(Benutzungsordnung für Telematik)) einzuhalten.
5.7. Serviceentwicklung (Life Cycle Management)
Die Informatikdienste behalten sich vor, die Serviceinfrastruktur laufend neuen Entwicklungen
anzupassen. Dies schliesst die regelmässige Installation von Updates ebenso ein wie die
Installation, Konfiguration einzelner Services, sowie deren Abbau oder den Ersatz der gesamten
Dienstleistung durch eine alternative Lösung.
Kleinere Serviceunterbrüche werden innerhalb der definierten Wartungsfenster durchgeführt. Bei
grösseren Unterbrüchen oder Änderungen im Grundangebot dieses SLAs wird vorgängig über
verschiedenste Informationskanäle informiert werden (ITEK, Verteilerliste für Mailadministratoren,
Informationsveranstaltungen usw.).
6. Allgemeine Richtlinien
6.1. Haftungsausschluss
Die Informatikdienste können nicht für Schäden verantwortlich gemacht werden, welche direkt
oder indirekt durch den Betrieb oder den Ausfall eines Dienstes oder Servers verursacht werden.
6.2. Generelle AGBs
Bei Unregelmässigkeiten, speziell bei Verdacht auf Hackeraktivitäten (passiv und aktiv) oder
anderen Auffälligkeiten, welche die Mailinfrastruktur in Teilen oder als Ganzes gefährden, haben
die Informatikdienste das Recht, die betroffenen Servicekomponenten jederzeit und ohne
Vorankündigung vom Netz zu nehmen, sowie weitere für die Sicherheit des ETH Netzwerkes und
den Ruf der ETH Zürich notwendige Massnahmen zu ergreifen.
6.3. BOT (Benutzungsordnung für Telematik)
https://rechtssammlung.sp.ethz.ch/Dokumente/203.21.pdf
https://rechtssammlung.sp.ethz.ch/Dokumente/203.21en.pdf
Seite 12 / 12Sie können auch lesen
