Sicherheitsempfehlungen zum Betrieb von Servern und
lokalen Netzen in Krankenhäusern
Lokale Netze und Client-Server-Systeme mit den Serverbetriebssystemen Windows
(NT, 2000, XP) oder Unix (Linux oder andere Varianten) werden immer häufiger
in Krankenhäusern eingesetzt, meist zusätzlich zu einem zentralen
Patientendaten-Verwaltungssystem. Dabei treten durch mangelnde
Fachkenntnis und zeitliche Überlastung des IT-Personals, aber auch aufgrund
von Sicherheitslücken in den Server-Betriebssystemen, Sicherheitsprobleme
auf, die wirksamen Datenschutz verhindern. Die Konfiguration eines
einigermaßen sicheren lokalen Netzes ist komplex und aufwendig. Dieser
Aufwand ist aber aufgrund der Datenschutzvorschriften unumgänglich,
sobald Patientendaten auf dem Server oder dem Netz gespeichert oder verarbeitet
werden; er sollte auch in allen anderen Fällen im eigenen Interesse nicht
gescheut werden und erfordert in jedem Fall eine Vollzeitstelle für einen
Systemverwalter. In dieser Empfehlung kann das Thema bei weitem nicht
erschöpfend behandelt werden. Nicht behandelt wird auch die Sicherheit
von Arbeitsplatzrechnern; hierzu wird auf
verwiesen. Ebenfalls nicht behandelt wird die Sicherheit der angebotenen
Dienste und Anwendungen; für HTTP-Server wird auf
vewiesen.
Grundsätzliches zur Sicherheit von Server-Betriebssystemen
Auf einem unsicheren Betriebssystem kann man keinen sicheren
Server aufsetzen. Daher ist der Sicherung des Betriebssystems
große Sorgfalt zu widmen. Prinzipiell lassen sich die gängigen
System-Plattformen hinlänglich sicher konfigurieren, wobei der
Aufwand nicht unterschätzt werden sollte. Die Wahl
zwischen Windows NT/2000/XP oder einem gängigen Unix-System (z. B.
Linux) sollte in erster Linie vom vorhandenen Know-How bestimmt
werden.
Windows NT (und seine Nachfolger 2000 und XP) wird oft als sicheres
Betriebssystem angepriesen. In der Tat
bietet NT einige Sicherheitsmechanismen, die für IT-Betreiber, die MS-DOS,
Windows 3 oder Windows 95/98/ME gewöhnt sind, sehr eindrucksvoll wirken.
Dieser Eindruck ist aber irreführend, zumal die Systemvoreinstellungen
nur wenige der möglichen Sicherheitsschranken in Kraft setzen. Ebenso wird
die Sicherheit eines Servers, besonders bei Windows-Systemen, durch Installation
und Betrieb von Anwendungssoftware in der Regel unterlaufen; manche
Anwendungssoftware funktioniert sogar nur mit unsicheren System-Einstellungen.
Auch die durch die Benutzungsoberfläche, besonders ab NT-Version 4.0,
suggerierte Leichtigkeit der Konfiguration ist irreführend und
gefährlich, da sie Nachlässigkeit provoziert. Hinzu kommt bei
Windows-Systemen, dass beim Einspielen von Bugfixes und »Service-Packs«
oft sorgfältig konfigurierte Sicherheitseinstellungen zurückgesetzt werden.
Unix-Systeme sind im Gegensatz dazu für den erfahrenen Systemverwalter
übersichtlicher. Die Einarbeitungszeit ist zwar möglicherweise etwas länger,
dafür sind aber die Systemprozesse und Fehlerbehebungsvorgänge wesentlich
leichter unter Kontrolle zu halten,
und die Konfiguration ist deutlich leichter nachvollziehbar; der Server ist
damit insgesamt leichter sicher zu halten.
Im Zweifelsfall ist daher ein Unix-System vorzuziehen. Wichtig ist in jedem
Fall eine »Härtung« des Servers. Das bedeutet unter anderem:
- Einspielen aller aktuellen Patches, Schließen aller bekannten
Sicherheitslücken. Hier sind vor allem die Hinweise des
CERT/CC laufend zu beachten.
Bei Windows-Systemen ist anschließend eine genaue Kontrolle und
gegebenenfalls Restaurierung aller vorher getätigten Sicherheitseinstellungen
nötig.
- Deaktivieren aller nicht benötigten Dienste (File-Sharing/NFS,
FTP, Mail, Telnet, RAS, RPC, ...) - jeder nicht benötigte, »vergessene«
Dienst ist ein potentielles Sicherheitsrisiko.
- Aufstellen des Servers in einem gesicherten, nicht allgemein
zugänglichen Bereich.
- Verwenden eines kryptographischen Dateisystems für Dateien und
Datenbanken mit personenbezogenen Daten. Unter Linux kann ein entsprechender
Treiber eingebunden werden, siehe
Unter Windows ist PGPdisk oder ScramDisk zu empfehlen:
Von der mit neueren
Windows-Systemen mitgelieferten Dateisystem-Verschlüsselung ist wegen
gravierender Mängel abzuraten.
- Soll ein HTTP-basierter Service angeboten werden, sollte man den Internet
Information Server (IIS) vermeiden.
Auch unter Windows ist der Apache-Server die sicherere Lösung.
- Administration des Servers nur über die Konsole. Falls die Administration
über einen Netzzugang nicht zu vermeiden ist, sollte ein
kryptographisch gesichertes Protokoll verwendet werden, also z. B.
im Unix-Bereich nicht Telnet, sondern SSH, das in den üblichen
Distributionen enthalten ist oder leicht nachgerüstet werden kann;
Quelle im WWW hier.
SSH-Clienten sind auch für Windows-Systeme kostenlos erhältlich.
Auch eine VPN-Verbindung ist bei passender Konfiguration geeignet.
Weitere Hinweise zur Serverhärtung findet man im WWW:
Das angestrebte Sicherheitsniveau sollte mindestens dem »mittleren
Schutzbedarf« im
entsprechen, soweit möglich auch darüber hinausgehen.
Um über aktuelle Sicherheitsfragen stets auf dem laufenden zu sein,
sollte der Systemverwalter mindestens eine
einschlägige Usenet-Newsgruppe oder Mail-Liste verfolgen.
Sicherheitsratschläge für Aufstellung und Konfiguration
von Servern
Um die Sicherheitsmechanismen des Betriebssystems wirkungsvoll einzusetzen,
ist eine ausführliche Planung, insbesondere der Zugriffsrechte, und eine
sehr sorgfältige Umsetzung nötig. Das Prinzip der minimalen Rechte
sollte bei der Zugriffsregelung strikt beachtet werden. Im Netz sollte genau
festgelegt werden, welcher Rechner in welche anderen welches Ausmaß an
Vertrauen setzt und welche Ressourcen an ihn freigegeben werden. Ebenso sollten
die Benutzer-Zugriffsrechte auf Ressourcen und Shares in einer Rechte-Matrix
spezifiziert werden.
Es sollte stets eine ausgedruckte Version der System-Konfiguration
einschließlich Vernetzungsplan und eine exakte Beschreibung der
Sicherheitspolitik (»Policy«, »Systemrichtlinien«) zur Hand sein. Die
Konfiguration sollte sorgfältig dokumentiert sein, insbesondere die
Sicherheitsmaßnahmen. Eine Auswahl wichtiger Sicherheitsmaßnahmen ist:
- Server sind physisch geschützt aufzustellen,
z. B. in einem verschlossenen Raum.
- Es ist sicherzustellen, dass unbefugte Benutzer nicht ein
alternatives Betriebssystem booten können.
Geeignete Maßnahmen hierfür sind:
- Aufstellung in einem verschlossenen Raum,
- verschließbares Sicherheitsgehäuse,
- keine Installation anderer Betriebssysteme oder
Betriebssystem-Versionen auf anderen Partitionen,
- Entfernung oder Verschluss der Diskettenlaufwerke,
- Einschränkung der Boot-Möglichkeiten in der
Hardware-Konfiguration,
- Setzen eines Hardware-Passworts
(nicht geeignet, wenn autoboot für den Server notwendig
ist),
- Setzen des Boot-Timeouts auf 0 Sekunden;
sie können einzeln oder in sinnvoller Kombination angewendet werden.
Die Benutzerkennung »Gast« ist stillzulegen, ebenso die Gruppe »Gäste«;
letzteres geht nur, wenn auf dem System nicht der Internet Information Server
laufen soll.
Die CD-Autoplay-Funktion ist abzuschalten.
Die Protokollierung ist, soweit sinnvoll, einzurichten. Um die Balance
zwischen der Aufzeichnung wichtiger sicherheitsrelevanter Vorgänge
und der Erzeugung einer nicht mehr überblickbaren Datenflut zu
wahren, sind dazu sorgfältige Detail-Überlegungen nötig.
Zugriff auf Log-Dateien sollte nur der Administrator haben.
Da NT die Protokollierung stillschweigend einstellt, wenn eine Log-Datei
voll ist, ist die Größe dieser Dateien stets sorgfältig
zu kontrollieren.
Der Zugriff auf die Konfigurations-Datenbank (Registry) ist soweit wie
möglich einzuschränken.
Auf Systemverzeichnisse (z. B. \winnt) und deren
Unterverzeichnisse dürfen gewöhnliche Benutzer und Prozesse nur
Lesezugriff haben.
Da Backup-Operatoren Lese- und Schreibzugang zum gesamten Dateisystem
haben, ist der berechtigte Personenkreis eng einzugrenzen; es sollte
eine besondere Benutzer-Kennung dafür verwendet werden, deren
Rechte genau an die Aufgabe angepasst sind.
Für alle Benutzer, auch die voreingestellten, sind
Passwörter zu setzen.
Die Auswahl von Trivial-Passwörtern sollte verhindert werden
(Passfilt.dll ab NT 4.0 mit SP2 verfügbar).
Als Maßnahme gegen das systematische Ausprobieren von
Passwörtern sollten folgende Vorkehrungen getroffen werden:
- Konto sperren nach 3 ungültigen Fehlversuchen.
- Konto zurücksetzen nach 30 Minuten (das betrifft den
Fehlversuchs-Zähler).
- Dauer der Sperrung: Für immer (bis der Administrator sie
aufhebt).
Unter Windows macht man das im Benutzer-Manager unter »Richtlinien«,
»Konten«.
Sicherheitsratschläge für den Systemadministrator
- Systemverwalter sollten eine Benutzer-Kennung
mit Administrator-Rechten nur für wirkliche
Verwaltungsaufgaben nutzen. Für Arbeiten, die nicht die vollen
Privilegien benötigen, sind gewöhnliche Benutzer-Kennungen
zu verwenden. Insbesondere sollte unter Administrator-Rechten nicht
mit Anwendungen gearbeitet werden, die für das Einschleusen von
Schadprogrammen anfällig sind, wie die MS-Office-Anwendungen,
E-Mail oder WWW-Browser.
- An Servern sollte, außer für Administrator-Aufgaben, nicht
lokal gearbeitet werden.
- Bei der Unterbrechung von Systemadministrator-Arbeiten sollte
ein Logout ausgeführt oder die Arbeitsstation gesperrt werden
(unter Windows im Task-Manager ([Strg]+[Alt]+[Entf])).
- Um das Aussperren des Systemverwalters und als Folge möglicherweise
eine längerdauernde Nichtverfügbarkeit des Rechners
oder einzelner Dienste (`denial of service'-Attacke)
zu verhindern, darf es für »Administrator« bzw. »root« keine
Passwortsperre nach mehreren Fehlversuchen geben. Daher
sollte man dessen Logon nur lokal zulassen.
- Um auch in Notfällen Administrator-Aufgaben wahrnehmen zu
können, sollte das Administrator-Passwort in einem
versiegelten Umschlag an sicherer Stelle, z. B. in einem Safe,
hinterlegt werden. Gleiches gilt für ein eventuelles
Hardware-Passwort und für Schlüssel zu Zugangstüren
oder Rechnergehäuse.
- Eine Anmeldung über das Netz oder gar über eine
unverschlüsselte Fernverbindung (mit RAS-Berechtigung) ist
unter Sicherheitsgesichtspunkten besonders kritisch zu werten. Als
mögliche Sicherheitsmaßnahme unter Windows können
im Benutzer-Manager unter »Benutzerrechte« in der Rubrik
»Zugriff auf diesen Computer vom Netz« die Gruppen »Administratoren«
und »Jeder« entfernt werden. Eine weitere, damit allerdings nicht
zu vereinbarende, Maßnahme ist die Einrichtung einer anderen
Kennung mit Administrator-Rechten, für die der Zugang über
das Netz möglich ist, allerdings die Passwortsperre bei
Fehlversuchen funktioniert.
- Als Logon-Möglichkeit über das Netz sollte nur ein verschlüsseltes
Protokoll (SSH unter Unix) zugelassen werden.
- Mitarbeiter sollten auf ihren Arbeitsplatzrechnern keine, auch
nicht die lokale, Administrator-Berechtigung erhalten; Ausnahmen sind nur
bei besonderen Systemkenntnissen möglich.
Die gelegentlich gehörte Empfehlung, die Administrator-Kennung mit
einem anderen Benutzernamen zu versehen, ist weitgehend nutzlos, da NT-Rechner
auf mehreren Wegen bereitwillig die Kennung des Administrators verraten.
Weitere Verweise ins Internet
- Vergleich der Betriebssysteme:
- Unix:
- Windows NT (und 2000):
Bücher zum Thema »Sicherheit unter Windows NT bzw. 2000« sind zwar zahlreich auf dem
Markt, aber z. T. von zweifelhafter Qualität und oft nicht auf dem
neuesten Stand. Aktueller und gründlicher kann man sich unter den
folgenden WWW-Adressen informieren:
- Windows 2000:
21. Oktober 2001.
Letzte redaktionelle Änderung: 26. Oktober 2001.
E-Mail:
Pommerening@imsd.uni-mainz.de